Vscode-remote-release: The content of the file is newer when on remote container

[dionysiosarvanitis]

• VSCode Version: 1.41.1
• OS Version: Windows 10 1909 18363.593

Steps to Reproduce:

1. Open a file in remote container
2. Edit and save it multiple times quickly

Tried manually disable all extension except for remote. No formatters at all. Date inside container is synced with host.

Message I'm getting below:

ERR doSave(4) - exit - resulted in a save error: Error: Unable to write file (Error: File Modified Since)

h {scheme: "vscode-remote", authority: "dev-container+643a5c686f6d655c446576656c6f7065725c776f726b73706163655c7068705c6b7964", path: "/var/www/html/webpack.mix.js", query: "", fragment: "", …}
authority: "dev-container+643a5c686f6d655c446576656c6f7065725c776f726b73706163655c7068705c6b7964"
fragment: ""
path: "/var/www/html/webpack.mix.js"
query: ""
scheme: "vscode-remote"
_formatted: "vscode-remote://dev-container%2B643a5c686f6d655c446576656c6f7065725c776f726b73706163655c7068705c6b7964/var/www/html/webpack.mix.js"
_fsPath: null
fsPath: (...)
__proto__: c

Failed to save 'webpack.mix.js': The content of the file is newer. Please compare your version with the file contents.

onDidNotificationChange @ notificationsAlerts.ts:40
(anonymous) @ notificationsAlerts.ts:26
fire @ event.ts:581
addNotification @ notifications.ts:171
notify @ notificationService.ts:101
onSaveError @ textFileSaveErrorHandler.ts:179
onSaveError @ textFileEditorModel.ts:932
(anonymous) @ textFileEditorModel.ts:792
processTicksAndRejections @ internal/process/task_queues.js:89
Promise.then (async)
(anonymous) @ textFileEditorModel.ts:748
processTicksAndRejections @ internal/process/task_queues.js:89
Promise.then (async)
doSave @ textFileEditorModel.ts:700
save @ textFileEditorModel.ts:626
(anonymous) @ textFileService.ts:659
doSaveAllFiles @ textFileService.ts:658
doSaveAll @ textFileService.ts:539
saveAll @ textFileService.ts:533
save @ textFileService.ts:507
save @ editor.ts:566
(anonymous) @ editorService.ts:696
save @ editorService.ts:688
K @ fileCommands.ts:387
V @ fileCommands.ts:349
handler @ fileCommands.ts:399
invokeFunction @ instantiationService.ts:67
_tryExecuteCommand @ commandService.ts:84
(anonymous) @ commandService.ts:73
Promise.then (async)
executeCommand @ commandService.ts:73
_doDispatch @ abstractKeybindingService.ts:196
_dispatch @ abstractKeybindingService.ts:155
(anonymous) @ keybindingService.ts:218

[bpasero]

@dionysiosarvanitis when you compare the file then do you see any differences?

As a workaround you can download insiders [1] and configure files.saveConflictResolution: 'overwriteFileOnDisk' as a workspace setting.

[1] https://code.visualstudio.com/insiders/

[paulriley]

I have seen the same problem in two locations since Docker for Windows updated to 2.2, developing .NET Core apps.

It happens on any attempt to save (autoSave or Ctrl-S).

If you ask it to compare, it shows all changes since the file was opened. If you then tell it to keep your changes, it does so, but that's a big change to workflow.

If you try to build using the terminal then it tries to build using the saved file (before any changes you've made). But, if you reload VS Code or even rebuild the container, the same changes remain in memory somewhere.

[Edit] I've downgraded to Docker for Windows 2.1.0.5 and the problem seems to have gone away. Of course, it's possible that being forced to refresh all images fixed it, but it seems more likely the "New file-sharing implementation" in Docker 2.2 is responsible somehow.

https://docs.docker.com/docker-for-windows/release-notes/

[dionysiosarvanitis]

Yes, If you compare, you can see some diffs. Thankfully at my home PC it works fine. The only difference between the two systems is the OS version: Windows_NT x64 10.0.18363 vs 10.0.19041. The latest version is the one without any issues. Thanks for the workaround.

[bpasero]

Is it possible that some other process is modifying the file? Are the changes show a version that was previously saved by you?

[dionysiosarvanitis]

Yes, it shows diffs previously saved by me. I tried with AV disabled. Can't think of anything else.

[bpasero]

@dionysiosarvanitis and you say this happened ever since Docker updated, so not something VSCode broke in recent updates?

[dionysiosarvanitis]

No, paulriley said that! I'm not sure since when it started, but I guess it was after windows upgraded to 1909 from 1809.

[bpasero]

Ok thanks. Moving to the remote repository, as this is remote specific.

[bpasero]

Note: setting name changed to files.saveConflictResolution and needs to be configured as overwriteFileOnDisk to disable the confirmation prompt.

[paulriley]

@dionysiosarvanitis Have you tried going back to Docker 2.1? That's worked for me in both locations. I may have time tonight to reapply the 2.2 upgrade on my home laptop, just to confirm.

@bpasero I'm fairly sure nothing would have been updating the file (especially that isn't updating in Docker 2.1, using the exact same container config). But it's possible. I'll see if I can confirm that at the same time.

[paulriley]

Upgrading to DfW 2.2 caused the problem to resurface. With some further testing, it appears to occur when you save twice (with changes) in a short period of time (sub-second). It happens much less if I turn auto-save off, which makes sense.

But, once the error occurs once, it occurs every time you try to save the same file, until you select Compare and tell it to keep your changes.

The file-edit date is not changing, so nothing else is causing edits. In one case, when comparing and keeping my changes, the file date was set to Jan 1 1970. But I guess that's a different issue. I couldn't recreate it.

[bpasero]

VSCode is using a combination of file modification timestamp and size to detect save conflicts. Basically:

• modification time has to be same or older than VSCode's working copy
• size needs to be same as VSCode's working copy

If any of the two is different, this error will occur. Given you mentioned that the modification time was once wrongly set to 1970, I wonder if something is broken with regards to that in the docker update.

[paulriley]

I wrote a script to monitor file date against current date to see if file date was ever greater than current date. It didn't show that to be the case.

But it did show that, in Docker for Windows 2.2, when VS Code saves a file, there are sometimes brief periods where the file date is Jan 1 2070, then it changes to current date _at the time it was initially saved_.

eg. with file time to the left, current time to the right:

2020-02-01 17:13:16.326737700 +0000 2020-02-01 17:13:16.912032822 +0000
2020-02-01 17:13:16.326737700 +0000 2020-02-01 17:13:16.926659223 +0000
2020-02-01 17:13:16.326737700 +0000 2020-02-01 17:13:16.943606523 +0000
2020-02-01 17:13:16.326737700 +0000 2020-02-01 17:13:16.963715124 +0000
1970-01-01 00:00:00.000000000 +0000 2020-02-01 17:13:16.992327124 +0000
1970-01-01 00:00:00.000000000 +0000 2020-02-01 17:13:17.021289725 +0000
1970-01-01 00:00:00.000000000 +0000 2020-02-01 17:13:17.047735625 +0000
1970-01-01 00:00:00.000000000 +0000 2020-02-01 17:13:17.063098926 +0000
2020-02-01 17:13:16.987792900 +0000 2020-02-01 17:13:17.082830126 +0000
2020-02-01 17:13:16.987792900 +0000 2020-02-01 17:13:17.108537527 +0000
2020-02-01 17:13:16.987792900 +0000 2020-02-01 17:13:17.120896027 +0000

Under normal circumstances, you probably wouldn't notice that, but it does seem possible that VS Code is storing this day-zero modification date as the working copy date and then seeing the file date as more recent, no matter what I do from that point.

I've reverted to Docker for Windows 2.1 again and run the same test, but the file never shows Jan 1 1970 as the last modified date. So yes, that would seem to be the difference between Docker versions.

If the process is as I described above, perhaps VS Code could work around this by saying "modification time has to be same or older than VSCode's working copy or VSCode's working copy has a day-zero modification time"? Alternatively, when it picks up the working copy, it could wait until there's a real modified date?

[bpasero]

This is a great analysis, I think it would make sense to file an issue against Docker at this point, no?

[paulriley]

Seems that there's already an issue against Docker for Windows:
https://github.com/docker/for-win/issues/5543

I guess my problem is that I'm trying to convince people that VS Code, remote in a container, is an absolute dream for .NET Core developers and this is not helping my cause. But DfW do claim to have a fix ready to go (I will test it later today), so I do understand if you want to close this off as a Docker problem.

Obviously, this is not my issue -- it belongs to @dionysiosarvanitis -- I was just able to reproduce it reliably, so helping with analysis.

[bpasero]

Thanks a lot for linking to this issue, from the last comment it seems a fix is in the works.

[paulriley]

Update: their "private" 2.2.0.1 build (linked to in the issue) does seem to resolve the VS Code Remote problem.

@dionysiosarvanitis Try that and see if it fixes your issues.

[dionysiosarvanitis]

@paulriley @bpasero I confirm that Docker 2.2 fixed it!

[dionysiosarvanitis]

For the record, problem solved in Docker 2.2.0.3, not 2.2.0.1.