
VS Code was lost on shutdown with pending update (2018) - teekert
https://github.com/microsoft/vscode/issues/52855
======
stevehawk
Maybe it's an A/B deployment where they want to see if we're more productive
without VS Code? ;-)

~~~
zelphirkalt
Or a new form of telemetry, where they want to collect life signs of people,
who need to redownload or post a comment in the issue.

------
skohan
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.

~~~
solarkraft
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.

~~~
skohan
There are a few things I don't like about it:

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.

------
godzillabrennus
I consider it a win when my IDE only deletes itself and doesn’t format my hard
drive in the process.

~~~
klysm
Did this happen?

~~~
pjc50
There have been a couple of incidents of self-destructing installers, yes. "rm
-rf /${VARIABLE}" where the variable isn't set, that kind of thing.

~~~
CodesInChaos
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.

~~~
klysm
Seems like --no-preserve-root is poorly implemented if that is allowed.

~~~
FreeFull
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 `/*`

~~~
klysm
True, but that still doesn't preserve root.

------
oefrha
At least 20% of my grief while using Windows stems from not being able to
remove or replace open files.

~~~
SketchySeaBeast
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?

~~~
cesarb
> 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.

~~~
SAI_Peregrinus
Or close the other program.

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.

~~~
cesarb
> 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...](http://technet.microsoft.com/en-
us/magazine/2009.04.windowsconfidential.aspx)

------
hprotagonist
Could be worse:
[https://github.com/microsoft/vscode/issues/32405](https://github.com/microsoft/vscode/issues/32405)

the famous “we changed the names of common git operations, oh boy was that a
bad idea” bug.

~~~
krthr
:( that was so sad

------
nn3
Wish more software would do that. Often we don't need it after all.

------
userbinator
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.

[1]
[https://news.ycombinator.com/item?id=18189139](https://news.ycombinator.com/item?id=18189139)

~~~
darrenkopp
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)

------
darrenkopp
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.

------
illuminated
Schrödinger's editor: it is there and it isn't.

------
alexeiz
This issue has been unfixed for two years, and it's still in the backlog? Wow.
Looks like Microsoft prioritization process is really broken.

------
jsilence
If only there were an emacs mode to do that!

