File can turn into empty file in certain cases

[zimbo73]

This problem occurs on VsCode v1.27.2, v1.28.2 and the Insiders version I downloaded today (1.29.0-insider), and rolling back to v1.26.1 no longer exhibits this problem. I also tested it with extensions disabled (--disable-extensions)

I have a small application watching JavaScript source files and when I save the file in VSCode they get copied to another folder (for debugging with Chrome). This app is a C# application that simply calls System.IO.File.Copy(sourceFile, destFile, true) where sourceFile is the file I am editing in VSCode, in response to a System.IO.FileSystemWatcher notification. As far as I can tell is simply uses Read access with a Read or Delete share mode.

Having used this mechanism for more than a year successfully, since updating recently it now appears that the Sharing Violations which are probably expected in this environment have a disastrous effect in that the file becomes a blank file (perhaps a brand new file replacing the previous file). Sometimes VSCode shows an error that says:

Failed to save 'myfile.jsx': A system error occured (EBUSY: resource busy or locked, open 'full/path/to/myfile.jsx')

or

Failed to save 'myfile.jsx': The content on disk is newer. Please compare your version with the one on disk.

I can reproduce this when simply starting VSCode with no extensions (--disable-extensions) (my "code watching" app is already running) and then pressing Ctrl+S (Save) to save the unmodified file. After between 1 and 5 presses of Ctrl+S the file becomes empty.

I have attach the raw Procmon.exe capture, where I started VSCode (no extensions), and a single Ctrl+S resulted in a blank file. Note the SHARING VIOLATION which I suspect is where the problem lies.
Logfile4.zip

Please let me know if there is anything else I can provide.

[zimbo73]

Adding the version info:
Version: 1.28.2 (user setup)
Commit: 7f3ce96
Date: 2018-10-17T00:23:51.859Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

[bpasero]

This sounds like it originates from the fact that you are tampering with the file with your C# program. I do not see how VSCode should change here, we are simply writing to the file using node.js APIs.

[zimbo73]

But the evidence in the Procmon capture shows that the tool only accesses the file in ReadOnly mode. Let me make a simple tool using the same API's to provide a simple repro.

[zimbo73]

CodeTestApp.zip
Attached is a C# (VS2017) simple test app and can easily reproduce the issue. It needs building as I am not sure on the rules for attaching an .exe, however I can attached a zipped up .exe if required.

It will do the following:

• Add a "Target" sub folder in the applications directory, if none exists.
• Create a "TestFile.txt" with some content in the applications directory, if it doesn't exist.
• Watches changes in the applications directory, and copies the changed files to the "Target" sub-folder.

Steps:

• Build CodeTestApp.exe (I am happy to supply an .exe if preferred)
• Run it
• Open "TestFile.txt" from the application directory in VSCode
• Press Ctrl+S multiple times in VSCode (goes wrong within 6 presses for me)
• Observe that either the content in the VSCode tab disappears, or the content on disk is now empty (I have seen both)

[zimbo73]

@bpasero should I open a new issue now that I have a reproducible test case? Or is the workflow that this issue is re-opened?

[bpasero]

Thanks, let's reopen this one then. I am setting the "help wanted" label so that someone can chime in. I suspect it is an issue with node.js though, so I will also set the node/upstream labels.

Some code pointers: we use doWriteFileStreamAndFlush method.

@zimbo73 if you want to help (and you seem passionate about this 👍 ), can you follow https://github.com/Microsoft/vscode/wiki/How-to-Contribute to setup VSCode to run locally from sources?

[bpasero]

My guess would be that this was introduced from the change (in 1.27.x?) to truncate (see https://github.com/Microsoft/vscode/blob/0ebf5f2d5f35515b8b9217516527b1269ea3d2ee/src/vs/workbench/services/files/electron-browser/fileService.ts#L597). But I will wait for you to be able to run out of sources so that we can validate that theory.

[bpasero]

You could also run with --verbose to see if you get the output "Truncate failed (${error}), falling back to normal save"

[zimbo73]

Thanks. Will try the --verbose option, and then look at compiling and running it locally.

[bpasero]

@zimbo73 thanks again for your application that allowed me to reproduce this issue. The issue is tricky to fix but I pushed a workaround, here is what happens:

• you hit Ctrl+S to save the file (the file is not dirty)
• we first truncate the file to 0 bytes (here)
• we then try to save the file
• meanwhile your application reacts to the file event from the truncate and keeps the file busy
• our save fails

My workaround is to retry the save after 100ms. Unfortunately the issue can still happen should the file be locked after 100ms. The reason why we truncate in the first place on Windows is due to a bug when writing to files with alternate data streams (https://blogs.technet.microsoft.com/askcore/2013/03/24/alternate-data-streams-in-ntfs/) that would otherwise get removed.

I feel like you deserve some swag for taking so much time to report this issue and your sample application. If you sign up for the Microsoft Hacktoberfest (https://open.microsoft.com/2018/09/30/join-hacktoberfest-2018-celebration-microsoft/) and create a simple PR (a change in any comment of any file I own is fine - like fileService.ts), I will make sure to merge it in and you should get that T-Shirt :)

[zimbo73]

Good find! I was away on a short vacation but will do so shortly.

[zimbo73]

Hi @bpasero - I did the PR (learning curve for me, hopefully all OK).

[bpasero]

@zimbo73 great, I merged it. You should get your T-Shirt 👍