Same issue here. Some empty files with random filenames are created when I open the folder using Remote SSH.

Some susceptible filenames seem like SQL.

Version: 1.65.2 (user setup)
Commit: c722ca6
Date: 2022-03-10T14:33:55.248Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19044

Remote OS is CentOS 7

Same issue here. Tried with all extensions disabled, same issue.

To make matters worse, some files are even modified to the point where the contents are erased. This happens in all sort of random files.

Seems to occur more often when building or configuring using, for example, cmake. But the severity of modified//added files is completely random.

I once had a filename that was about 100 characters long and looked like a string dump from a running process as it had a table 'look a like' string of characters.

Version: 1.65.2 (user setup)
Commit: c722ca6
Date: 2022-03-10T14:33:55.248Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19042

I have this happening on two unrelated machines.

I meet the same situation
Version: 1.65.2 (Universal)
Commit: c722ca6
Date: 2022-03-10T14:33:49.188Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0

I have just downgraded (by installing without uninstalling) 1.64.2, the issue persists

Same issue here. I haven't been able to find out what exactly is the trigger but I know it's definitely caused by vs code because when I tried to write stuff using neovim or kate, these files don't appear.

From what I can tell, these files only appear in the root of the folder (and not in any subdirectories in the project). The names of these files are not valid unicode (e.g. \312\316\361 which is in octal is 11001010 11001110 11110001 in binary).

System Info

Extensions

From what I can tell, these files only appear in the root of the folder (and not in any subdirectories in the project).

This statement is incorrect. I get original files being emptied in my build tree and get files named cpp.hint in my build tree

edit:
I've just got a file name cpp.stop

Seems like if you are using Remote SSH, you can temporarily resolve the issue by deleting ~/.vscode-server and reopening VSC. I don't know if the same issue would happen again.

For me personally I am not using Remote SSH.

Additional information. The deletion of contents of files was not restricted to my working folder!

It has even managed to delete contents outside this folder, for example my 'windows kits' has been destroyed and I don't know to what extend, but the following file, for example, is completely empty now:

I do not know if the issue is only affecting parsing of 'include' files or that it could possibly have touched completely unrelated files as well.

A few more files were affected:

Searched on size 0, modified today

This preview introduces this bug.

This preview introduces this bug.

How would this explain that the issues persisted with all extensions disabled?

This preview introduces this bug.

How would this explain that the issues persisted with all extensions disabled?

Switching to the official release solves this problem temporarily.

In my case, I disable all extensions and restart vscode. Files are generated just after reenabling cpptools.

Maybe there are still running process in the background or so. After I rollback to release branch, the problem just goes away.

I'm also suspecting the file-deletion issue ruined my dev docker twice. I found many header files become zero-sized and even pthread won't work.

I wonder if this issue is being caused by an installed extension. Can you try to run VS Code without extensions? From the command line (NOT the integrated terminal in Code), execute: code --disable-extensions and try your steps again to see if it reproduces. If you see it is an issue with the extension, please file it against the extension repository itself.

I traced this to 1.9.4 pre-release of the C/C++ extension.
I can trigger the problem when there are updates to the files in the project folder.
With all extension disabled the problem goes away.
The problem also goes away if I switch to the release version (1.8.4)

node-ipc?

Man, I can't wait to read the blog post explaining what happened here

This bug has caused ripples through the PlatformIO community in the last 24 hours.

Can anyone tell me how I picked up this pre-release this morning without knowing? I would not be knowing running any pre-release of software (I have enough problems of my own creation! ) - Has it automatically deployed everywhere?

Can anyone tell me how I picked up this pre-release this morning without knowing?

I recall seeing someone on reddit say they thought it was because they installed the language extension while it was still in pre-release. After some time had passed, the extension officially released, however vscode still had them marked down as pre-release, so it kept installing the new pre-release versions, which eventually led to some of their files becoming corrupted today.

c/c++ extension v1.9.4 's problem.
microsoft/vscode-cpptools#9046

Thank you @sean-mcmanus - believe me - I am absolutely delighted that you have found this - The alternative would point (in my mind) to some security attack/breach.

I don't know if anything provided helped, but I would be more than happy to be involved in forensics on these matters.
I have a long history in safety critical systems and high value financial services, so I do get twitchy when the unexplained happens and I strive to get to the root cause.

Have a great day (if there is any left!)

Yeah, there was no security attack or breach -- just an accidental usage of uninitialized memory from a modification to an external third party subsystem that doesn't follow modern C++ coding guideline that could have prevented or detected usage of uninitialized pointers (like our main code base does).

Yeah, there was no security attack or breach -- just an accidental usage of uninitialized memory from a modification to an external third party subsystem that doesn't follow modern C++ coding guideline that could have prevented or detected usage of uninitialized pointers (like our main code base does).

Oof, that sounds like a deep deep deeeeeep rabbit hole to find. Good on finding though!

Can anyone tell me how I picked up this pre-release this morning without knowing?

I recall seeing someone on reddit say they thought it was because they installed the language extension while it was still in pre-release. After some time had passed, the extension officially released, however vscode still had them marked down as pre-release, so it kept installing the new pre-release versions, which eventually led to some of their files becoming corrupted today.

That was me. I've had my installation for the past 4 years :-). Even the 'insiders' configuration in my settings file was still there from a long long time ago. For me the insiders setting carried over, I guess, to the pre-release version of the 'new new way' that extensions were updated.

But then again, this issue could easily, as it sounds, have slipped in a proper released version. So, sometimes shit just hits the fan.

@daantimmer I don't believe this bug would've made it into the non-pre-release builds, because we have a policy of shipping changes to the pre-release version first and then releasing into the non-pre-release after things seem okay after a few days...with "last minute" changes generally only occurring if we believe it's a low risk fix.

@daantimmer I don't believe this bug would've made it into the non-pre-release builds, because we have a policy of shipping changes to the pre-release version first and then releasing into the non-pre-release after things seem okay after a few days...with "last minute" changes generally only occurring if we believe it's a low risk fix.

I was not trying to imply that this specific bug could have slipped through. Was trying to imply that nobody is ever perfect and mistakes can happen. Even on a thoroughly tested release. "Looking at you, any random game development studio" :-)

Hello
Due this bug the content of one of my source file which had 3000 line, was deleted .
I don't use version control system.
How can i restore it?

@TavakoliAli Unfortunately, there is no way to restore the file (as far as I know). You should consider using a source control system such as git, cloud storage backup, etc.. Using the non-pre-release version of the C/C++ extension (1.8.4) would also be recommended. File deletion/corruption bugs are pretty rare. That last one we had was a couple years ago during code formatting in a multi-root workspace ( microsoft/vscode-cpptools#1073). In fact, we still have a bug where formatting on a symlinked workspace folder can corrupt files ( microsoft/vscode-cpptools#5061), which has a root cause of microsoft/vscode-cpptools#4573.

@sean-mcmanus , @hello-smile6 - thank you
Indeed the default setting in VSC is enabled!

Wow! That seems pretty dangerous!
I don't know what controls are put over the Extension Marketplace but we have just seen a small example of a change that happened invisibly and caused widespread confusion.
My config is now changed from default to 'None'
I can't prove it but I don't believe I opted into the pre-release version. Is there any log of Extension updates in VSC?

Due this bug the content of one of my source file which had 3000 line, was deleted .

This is the first post that mentions deletion of source files? Are there other examples?
So far I have detected in my system:

• Creation of zero length files in the active folder in my workspace
• No deletion of my code
• But rewriting to zero length files in the packages folder of the extension I was using (PlatformIO in my case) - these packages could 'simply' be deleted and reloaded

Due this bug the content of one of my source file which had 3000 line, was deleted .

This is the first post that mentions deletion of source files? Are there other examples? So far I have detected in my system.

I've had source and header file contents deleted. Both in source control, but also in my windows SDK installation. I've mentioned this here and there as well :-)

@sean-mcmanus , @hello-smile6 - thank you Indeed the default setting in VSC is enabled! Wow! That seems pretty dangerous! I don't know what controls are put over the Extension Marketplace but we have just seen a small example of a change that happened invisibly and caused widespread confusion. My config is now changed from default to 'None' I can't prove it but I don't believe I opted into the pre-release version. Is there any log of Extension updates in VSC?

Should be in /var/log or something.

Should be in /var/log or something.

Sounds like Linux? not Windows 10?

Should be in /var/log or something.

Sounds like Linux? not Windows 10?

Then try C:\Windows\system32\drivers\var\log or wherever logs would be stored.

Ah - if only Windows and Windows developers were so consistent!

No such logs and I cannot find anything in Google searches. Perhaps @sean-mcmanus can let us know if there is such for logging installations/updates in VSC?

Ah - if only Windows and Windows developers were so consistent!

No such logs and I cannot find anything in Google searches. Perhaps @sean-mcmanus can let us know if there is such for logging installations/updates in VSC?

Maybe use a VM and wine?

@mhavill I'm not familiar with any logging in regards to installation of extensions (someone on the VS Code team might know). I know that prior to VS Code's pre-release feature we had our own custom C_Cpp.updateChannel "Insiders" setting, so if you had that setting set somehow, then you got auto-migrated to the VS Code's new pre-release mechanism and we had a dialog box that appeared that prompted users to switch to the Insiders build, so you may have clicked that.

Thanks @sean-mcmanus. Maybe someone will pick it up in the future!?
I won't disturb you more. My system is all back to normal with no major impact.

"Insiders" setting, so if you had that setting set

I am most definitely an outsider not an insider :) It'll be a mystery.

Due this bug the content of one of my source file which had 3000 line, was deleted .

This is the first post that mentions deletion of source files? Are there other examples? So far I have detected in my system:

So i have all problems you mentioned. I rewrote header and deleted null files but i don't have enough time to rewrite source file.

Could it be a disk issue? Maybe check the lost+found directory.

The issue was a temp file string pointer that in some cases ended up pointing to memory that was deleted/invalid, so if that location in memory happened to be filled with a string for an existing file (that was writable), then that file could have been emptied. In most cases, the memory was filled with "garbage" data.

The issue was a temp file string pointer that in some cases ended up pointing to memory that was deleted/invalid, so if that location in memory happened to be filled with a string for an existing file (that was writable), then that file could have been emptied. In most cases, the memory was filled with "garbage" data.

Wow, that sounds problematic!

FINALLY! I thought my hard drive was failing. This issue is exactly what I exprenced last week! I've lost half a day of uncommited code being worked on because of this bug. Many headers from my cross compiler got wiped out to 0 byte. I never consented to get pre-release of my exentions, but my settings.json had a C_Cpp.updateChannel set to Insider and I am certain that I didn't do that. Not sure how it happened.

Issue confirmed! It still keeps generating me a number of alien (invalid encoding) files.

@rangsimanketkaew We shipped an update with a fix 12 days ago. What version (of the C/C++ extension) are you using? You should probably be using 1.9.7 (or 1.9.6, which is identical, but 1.9.5 a fix too). We haven't received any reports yet of invalid or erased files with those versions. If you repro the issue without the C/C++ enabled, then it's a different issue.

I opened issue #145676 mentioned above. I am using C/C++ extension version 1.9.7 and I can't report any new rogue files being created but has anyone found a way of deleting the ones created earlier? I posted the below in #145676.

If you look at the screenshot in my opening post you'll see there's an option to 'Create File' which I only just noticed myself. Today I tried this option for one of the offending files, added content to it, saved it and then tried deleting it. The deletion seemed to go smoothly (i.e.. no error message) but the filename just immediately pops back into place in vs code explorer and, when clicking on it, I'm back to 'File does not exist' square one.
Even tried renaming it 'rubbish' after saving it and, although 'rubbish' disappears after deletion the original gobbleydook name returns in explorer.

I opened issue #145676 mentioned above. I am using C/C++ extension version 1.9.7 and I can't report any new rogue files being created but has anyone found a way of deleting the ones created earlier? I posted the below in #145676.

If you look at the screenshot in my opening post you'll see there's an option to 'Create File' which I only just noticed myself. Today I tried this option for one of the offending files, added content to it, saved it and then tried deleting it. The deletion seemed to go smoothly (i.e.. no error message) but the filename just immediately pops back into place in vs code explorer and, when clicking on it, I'm back to 'File does not exist' square one.
Even tried renaming it 'rubbish' after saving it and, although 'rubbish' disappears after deletion the original gobbleydook name returns in explorer.

What if you delete them by inode number?

What if you delete them by inode number?

WOW. I had to look that up and then delete each one individually but it worked. I feel cleansed now. Thanks hello-smile6.