If this bug would cause you any significant damages whatsoever, you're doing it wrong. Hard disks fail all the time. This bug is quite analogous to a harddisk failing. Backup everything that matters.
Even if you did somehow manage to lose enough money that the damages could bankrupt Valve (or even pay for your lawyer), I doubt you would win. Basically all software these days disclaims all warranties. This wasn't malicious or particularly out of the ordinary for this industry.
That one doesn't work on systems which disallow deleting `/` unless you pass `--no-preserve-root`. But `rm -rf `${VARIABLE}/*` still does, and that's what steam did.
Well, once the glob gets expanded by the shell, the `rm` executable sees something like `-rf` `/home` `/usr` `/etc`, and isn't aware that the argument was `/*`
Sometimes Windows will release a stuck file if you kill explorer and restart it from task manager. I found it mostly happens while working with files in a program while the folder is open in explorer.
As a native windows user I don't really understand this grief - if the file is open we're kind of assuming we need it, aren't we? What happens if the system tries to read the file on disc and it's been replaced or removed? Why shouldn't that end in an earth-shattering kaboom?
Isn't the problem actually not being able to effectively close it to then replace it?
There are three kinds of semantics for non-collaborating programs that people want from files that are completely incompatible:
- update immediately(ish) seen by other users of the file (e.g. database); the default UNIX semantics, even for executables
- update seen by other users at the next point they open the file (what you want for update-without reboot, can be achieved on UNIX because deleted inodes hang around)
- it's completely impossible for other users to write, rename etc the file (Windows default)
Thanks! I guess each come with their own tradeoffs - immediate updates have a good chance of blowing away the current users work as well as continually searching for file updates, and a versioning system then needs to figure out what to do when the user saves a stale file.
gvim already handles this. If a file changes it prompts you to update or not. If you try to save an old file over a new one, it makes you confirm what you are doing.
A lot of times the problem actually comes down to not being able to find out what process is keeping a file open and/or not being able to close the process or file.
Process Explorer is the workarond. Use its search for handle, find the filename. You'll get a list of all handles to the file, and thus all processes with it open. You can close those (safest way) or force-close the handle (more likely to crash the process in question).
File and it's directory entry are two separate things. So you can remove and replace open file, but the old handle will still point to the old file - it just won't be open-able using the original filename. Once all the processes will close the handle to the old file, and no directory entry points to it, it will be removed from the file system.
Default UNIX semantics: you don't actually know this has happened to a file you're using on most filesystems, so you can continue writing to it and it will vanish on close.
Many programs do the "write to temp file and rename on top of old file" trick, which is almost-atomic, and you can have multiple programs doing that to the same file at the same time without noticing.
(If you're on NFS writing to a deleted inode may do something different and probably broken)
Doesn't that end up being dangerous as far as updates? You keep blowing away the file?
I think part of my problem is I'm visualizing this as a shared file being updated by users, and not, say, system updates. System updates make sense - we can assume only the system will be modifying them, and it'll be relatively low touch, but I keep visualizing a shared text document.
That opens an entirely new can of worms, called "file locking & unix".
Usually these multiple processes have some agreed way to take their turn on writing; or they use library like sqlite (or berkeley db in the past), that library brings that mutually-agreed locking mechanism with it.
Noncooperative shared text documents only kind of work at the user level like in notepad++ or vscode where it keeps an eye on the timestamp and offers to lose either the edits in memory or the edits on disk. Inserting things into the middle can't be done without rewriting everything after.
The only thing that does work with shared writing is logiles with O_APPEND, where multiple processes can safely add to the end of a file.
(For historical examples of this, have a look at mbox locking versus maildir; the "mbox" format is basically keeping all your email as a huge text file, and locking protocols have developed around that so multiple mail clients can coexists without wrecking it)
When a file is renamed or removed (replace is basically remove followed by rename -- often in one atomic action, of course), the open file handle and the corresponding inode can be left around and remain usable until the handle is closed. That is orthogonal to whether the filesystem path should be bound to the inode throughout its lifetime. On *ix systems it's not, so for instance a program could easily replace itself with a new version.
> Isn't the problem actually not being able to effectively close it to then replace it?
Not sure what this is supposed to mean. The program that's keeping the file open could effectively close it. The problem is other programs can't, plus it's hard to hunt down the process that's hanging on to a file.
This was solved in Unix land 50 years ago. Unlinked handles remain usable until the process releases them but the filesystem isn't held hostage. Doesn't require hunt the process to find out who has a file open. The OS can update itself live without a reboot.
there's a lot of instances where the system can the file locked when you don't think you have it open. preview pane in file explorer used to open an instance of the relevant software to generate a preview thereby locking the file. most Adobe products can fail to release a lock. weird filenames can prevent deletion in file explorer, but cmd can delete. sometimes windows locks the file while a thumbnail is being generated. these are the things that keep me up at night
This makes sense in theory, unless it's like on Windows where the file/storage is accessed by some unknown, hidden process that you don't know anything about except that it really likes to use this specific file, and you only have the choice between shutting down the computer to safely remove some thumb drive or to just pull it and hope for the best.
> if the file is open we're kind of assuming we need it, aren't we? What happens if the system tries to read the file on disc and it's been replaced or removed? Why shouldn't that end in an earth-shattering kaboom?
On Unix, the directory entry does not point directly to the file contents. It points to an "inode", which contains the file metadata (owner, permissions, timestamps) and points to the file contents. When you remove a file, you are actually removing the directory entry; the inode will only be removed when nothing else points to or is using it. An open file keeps a reference to the inode, so the system can still read the file just fine, even if the directory entry has been removed.
Some other operating systems, like MS-DOS and Windows 9x, do not have that distinction. On them, the directory entry has the same role as the inode on Unix-style systems, which means it cannot be removed while the file is in use. The Windows NT line, when using NTFS, does have something similar to the directory entry and inode split from Unix, but it still denies removing or replacing in-use files for compatibility with Windows 9x.
> Isn't the problem actually not being able to effectively close it to then replace it?
The problem is when another software (for instance, a file indexer or an antivirus) has the file open. You cannot force the other program to release its grip on the file; the workaround is to set the "pending delete" flag for the file and schedule a reboot.
Also, "You cannot force the other program to release its grip on the file; the workaround is to set the "pending delete" flag for the file and schedule a reboot. " is somewhat wrong. You can close the handle the other program holds on the file, it just might crash that other program.
> You can close the handle the other program holds on the file, it just might crash that other program.
It might do more than just crash that other program. Some other component within that program might open a new file (or even things which are not really files), and happen to get the same handle you had just closed (once the handle is closed, its number can be reused). Then the original component finishes what it was doing and closes the handle; the second component thinks it's still open. A third component opens a new file, and again gets the same handle. Now the second component tries to write to the handle (it might be something like a log file), and the write goes to the wrong place.
Force closing a handle on a different process leads to undefined behavior, and as always with undefined behavior, anything can happen.
First, there are more OSes out there besides Windows and UNIX.
Examples of insane behavior of UNIX's lack of locking:
- A process can get its file corrupted because flock() is cooperative, so there isn't any enforcement that even if file locking is used, it actually works. Hence the dance with temporary lockfiles as workaround.
- A process can happily store important information into a file just to have it deleted under its feet after the usage count of the inode goes to zero, and good luck bringing the data back to life without forensics tools.
Yes, but as a user rather than developer, I have never had a problem with it in practice, unlike Windows. And it is honestly much more convenient (as a user) to be able to manipulate open documents on the filesystem if you can keep in mind how the semantics work.
Maybe in theory, but it has never actually happened to me. I don't see much *nix user/sysadmin advice around the internet about how to avoid all those inevitably corrupted files, but there is plenty of evidence that Windows' strict locking causes real users real annoyance.
In theory only bad programmers write C code that corrupts memory, and yet it happens even in projects with top coders and multiple levels of code reviews.
Files are just memory in a different storage device.
>In theory only bad programmers write C code that corrupts memory, and yet it happens even in projects with top coders and multiple levels of code reviews.
In theory only bad programmers write code with bugs related to Windows file locking, and yet... well just check the OP I guess
You can rename them, which is the way "in-place" updates like these are usually done - the old file is renamed, the new file is copied into place, and an entry is set up in the registry to delete the old one upon the next reboot.
More than 20% of my grief comes from having to confirm the change of a file's extension, every time.
This happens when I start a script or a LaTex file etc by right-clicking in an empty folder to create a new text file, then changing the name of the file and its extension. It's an empty file with a .txt extension, yet windows has to ask me whether I'm sure I really want to perform this desperate and dangerous act that might cause some programs to not work any more.
VS Codium is an open source IDE. Binaries of VS Code, distributed by Microsoft, contain additions with telemetry and god knows what else, so for all intents and purposes, they should not be considered open source.
If we're being overly pedantic, the Visual Studio Code that you download from https://code.visualstudio.com/ isn't actually open source. It's analogous to Google Chrome with the source on GitHub analogous to Chromium.
Late reply but "With the exception of branding and configuration values, this open source base is identical to the built software product we offer" is about as integrated into open source as you can possibly expect a company with trademarks and branding like MS to adopt, right?
This is one of my biggest gripes with VSCode: it's always doing things for me. Like I don't need automatic updates, and I don't need suggestions popping up in the corner about which extensions to install.
Clippy didn't die, MS just moved him into the background.
I don't know - I think in 90% of cases I don't need software to be "smart", I want it to do exactly what I tell it and nothing else.
After using Linux more as a daily driver lately, all that "convenience" you get with macOS and Windows - the form of automatic updates and notifications - is incredibly distracting.
I know this isn't popular on here and it doesn't always apply, but ...
... I actually like it most of the time. Not the annoying update message, but when I open a .rs file I actually do want the plugin for syntax highlighting. VSC makes getting such stuff wonderfully easy.
1. Yeah it's easy, but it's not much easier than searching and installing a package in Sublime Text. And when I'm using a tool I want to be focused on the work, I don't want to be distracted by what MS thinks I want to see when I open my editor. Yeah it only takes a second to dismiss these things, but all these little distractions pulling you out of flow add up. It's amazing how relaxing it is when you don't have that all the time.
2. I don't want to become dependent on it honestly. Like what if VSCode starts to go in a direction I don't like, and I want to change editors, but my workflow depends on all these plugins which I don't even know what they are or how they work because I just installed them mindlessly like a monkey pressing a button in a lab to get a treat.
3. It's part of this whole ethos where software has to be constantly evolving, and developers need to collect data on everything users do to optimize for whatever KPI MS cares about. This goes along with things like A/B testing UI changes, so maybe one day I open VS Code and the menu options are different because they are testing something out on me. Ostensibly that's for my benefit, but it costs me productivity when I am just trying to get some work done.
A text editor is a simple thing. Basically I just don't need any of this extra stuff on top for a tiny little benefit.
When I first read this issue, I was assuming the user was losing unsaved code in their editor, which seemed like user error and I thought they had resolved that issue long ago. After reading the comments and reading the summary again, I'm pretty sure that this is actually the background updater has downloaded, detects that code is closed and starts to update automatically, but since the computer is rebooting, it gets killed.
The first comment about just checking if shutdown is in progress should work.
I'd be very curious to know why this would happen now, since VS Code has been around for a while and this would not be the first time people have installed an update for it. The functionality to move/delete files upon reboot has been around for much longer in Windows, and unless there is a bug in that (highly unlikely, but maybe less so these days[1]), I'm perplexed at this failure.
I think it's shutdown of the computer, not shutdown of VS code. The updater starts executing during the shutdown and I'm guessing the system is terminating the install process and it's not rolling back appropriately (or it is rolling back but only after the uninstall has executed)
I was always amazed by windows losing my preferences on update. As a software engineer who's worked on front end before I feel like I would have to hand in my union card if I shipped software which did that.
93 comments
[ 1.0 ms ] story [ 141 ms ] threadEven if you did somehow manage to lose enough money that the damages could bankrupt Valve (or even pay for your lawyer), I doubt you would win. Basically all software these days disclaims all warranties. This wasn't malicious or particularly out of the ordinary for this industry.
Isn't the problem actually not being able to effectively close it to then replace it?
- update immediately(ish) seen by other users of the file (e.g. database); the default UNIX semantics, even for executables
- update seen by other users at the next point they open the file (what you want for update-without reboot, can be achieved on UNIX because deleted inodes hang around)
- it's completely impossible for other users to write, rename etc the file (Windows default)
1. It’s not built into Windows, requires separate download;
2. Searching is hit or miss.
File and it's directory entry are two separate things. So you can remove and replace open file, but the old handle will still point to the old file - it just won't be open-able using the original filename. Once all the processes will close the handle to the old file, and no directory entry points to it, it will be removed from the file system.
Many programs do the "write to temp file and rename on top of old file" trick, which is almost-atomic, and you can have multiple programs doing that to the same file at the same time without noticing.
(If you're on NFS writing to a deleted inode may do something different and probably broken)
I think part of my problem is I'm visualizing this as a shared file being updated by users, and not, say, system updates. System updates make sense - we can assume only the system will be modifying them, and it'll be relatively low touch, but I keep visualizing a shared text document.
Usually these multiple processes have some agreed way to take their turn on writing; or they use library like sqlite (or berkeley db in the past), that library brings that mutually-agreed locking mechanism with it.
The only thing that does work with shared writing is logiles with O_APPEND, where multiple processes can safely add to the end of a file.
(For historical examples of this, have a look at mbox locking versus maildir; the "mbox" format is basically keeping all your email as a huge text file, and locking protocols have developed around that so multiple mail clients can coexists without wrecking it)
> Isn't the problem actually not being able to effectively close it to then replace it?
Not sure what this is supposed to mean. The program that's keeping the file open could effectively close it. The problem is other programs can't, plus it's hard to hunt down the process that's hanging on to a file.
On Unix, the directory entry does not point directly to the file contents. It points to an "inode", which contains the file metadata (owner, permissions, timestamps) and points to the file contents. When you remove a file, you are actually removing the directory entry; the inode will only be removed when nothing else points to or is using it. An open file keeps a reference to the inode, so the system can still read the file just fine, even if the directory entry has been removed.
Some other operating systems, like MS-DOS and Windows 9x, do not have that distinction. On them, the directory entry has the same role as the inode on Unix-style systems, which means it cannot be removed while the file is in use. The Windows NT line, when using NTFS, does have something similar to the directory entry and inode split from Unix, but it still denies removing or replacing in-use files for compatibility with Windows 9x.
> Isn't the problem actually not being able to effectively close it to then replace it?
The problem is when another software (for instance, a file indexer or an antivirus) has the file open. You cannot force the other program to release its grip on the file; the workaround is to set the "pending delete" flag for the file and schedule a reboot.
Also, "You cannot force the other program to release its grip on the file; the workaround is to set the "pending delete" flag for the file and schedule a reboot. " is somewhat wrong. You can close the handle the other program holds on the file, it just might crash that other program.
It might do more than just crash that other program. Some other component within that program might open a new file (or even things which are not really files), and happen to get the same handle you had just closed (once the handle is closed, its number can be reused). Then the original component finishes what it was doing and closes the handle; the second component thinks it's still open. A third component opens a new file, and again gets the same handle. Now the second component tries to write to the handle (it might be something like a log file), and the write goes to the wrong place.
Force closing a handle on a different process leads to undefined behavior, and as always with undefined behavior, anything can happen.
Raymond Chen also has an article about this: http://technet.microsoft.com/en-us/magazine/2009.04.windowsc...
Examples of insane behavior of UNIX's lack of locking:
- A process can get its file corrupted because flock() is cooperative, so there isn't any enforcement that even if file locking is used, it actually works. Hence the dance with temporary lockfiles as workaround.
- A process can happily store important information into a file just to have it deleted under its feet after the usage count of the inode goes to zero, and good luck bringing the data back to life without forensics tools.
Quite sane indeed.
Many people also swear that only bad programmers write C programs with memory corruption bugs.
Files are just memory in a different storage device.
In theory only bad programmers write code with bugs related to Windows file locking, and yet... well just check the OP I guess
This happens when I start a script or a LaTex file etc by right-clicking in an empty folder to create a new text file, then changing the name of the file and its extension. It's an empty file with a .txt extension, yet windows has to ask me whether I'm sure I really want to perform this desperate and dangerous act that might cause some programs to not work any more.
Telemetry is plainly visible in the VS Code source: https://github.com/microsoft/vscode/tree/8ffcb49f4fbeb250405...
VS Code is open source. It's MIT licensed. You can get the source code here: https://github.com/microsoft/vscode
Explanation from Microsoft employee: https://github.com/Microsoft/vscode/issues/60#issuecomment-1...
Visual Studio Code license: https://code.visualstudio.com/license
Official vscode faq - licensing section https://code.visualstudio.com/docs/supporting/faq#_location
MIT Licenced
Am I missing something?
Though, if you used your package manager to update. I don't think the posted issue would have happened.
Try https://vscodium.com/ for a fully open source version
Clippy didn't die, MS just moved him into the background.
Sadly, the same can be said for a lot of other software these days.
After using Linux more as a daily driver lately, all that "convenience" you get with macOS and Windows - the form of automatic updates and notifications - is incredibly distracting.
... I actually like it most of the time. Not the annoying update message, but when I open a .rs file I actually do want the plugin for syntax highlighting. VSC makes getting such stuff wonderfully easy.
VS Code pops up three notification windows every time I open a .py despite me having closed them literally hundreds of times now.
Apparently it’s smarter than me, and just knows I need its plugins and system integrations despite a year of adamantly refusing.
1. Yeah it's easy, but it's not much easier than searching and installing a package in Sublime Text. And when I'm using a tool I want to be focused on the work, I don't want to be distracted by what MS thinks I want to see when I open my editor. Yeah it only takes a second to dismiss these things, but all these little distractions pulling you out of flow add up. It's amazing how relaxing it is when you don't have that all the time.
2. I don't want to become dependent on it honestly. Like what if VSCode starts to go in a direction I don't like, and I want to change editors, but my workflow depends on all these plugins which I don't even know what they are or how they work because I just installed them mindlessly like a monkey pressing a button in a lab to get a treat.
3. It's part of this whole ethos where software has to be constantly evolving, and developers need to collect data on everything users do to optimize for whatever KPI MS cares about. This goes along with things like A/B testing UI changes, so maybe one day I open VS Code and the menu options are different because they are testing something out on me. Ostensibly that's for my benefit, but it costs me productivity when I am just trying to get some work done.
A text editor is a simple thing. Basically I just don't need any of this extra stuff on top for a tiny little benefit.
The first comment about just checking if shutdown is in progress should work.
[1] https://news.ycombinator.com/item?id=18189139
the famous “we changed the names of common git operations, oh boy was that a bad idea” bug.