Linked by Thom Holwerda on Wed 25th Jul 2018 22:54 UTC

A lot of people seem to dislike the way Windows install updates, and Microsoft seems to be doing something about it. In current test builds, it's improving the update experience.

Have you ever had to stop what you were doing, or wait for your computer to boot up because the device updated at the wrong time? We heard you, and to alleviate this pain, if you have an update pending we've updated our reboot logic to use a new system that is more adaptive and proactive. We trained a predictive model that can accurately predict when the right time to restart the device is. Meaning, that we will not only check if you are currently using your device before we restart, but we will also try to predict if you had just left the device to grab a cup of coffee and return shortly after.

I've never had any issues with Windows updates - they just install automatically overnight, long after I went to sleep, and hours before I wake up and start using my PC again.

Permalink for comment 660387
To read all comments associated with this story, please click here.
RE: Not the right fix
by malxau on Thu 26th Jul 2018 08:35 UTC in reply to "Not the right fix"
Member since:

On the other hand, Windows chose to lock "files in use" when its filesystem was designed.

This is a bit of a simplification. Windows lets the thing opening the file decide what access later openers get to have. These are called sharing modes; see CreateFile's dwShareMode parameter. Running executables are a bit of a special case with unique semantics, which do not allow delete but do allow rename.

In Linux, you can replace a file that's in use with an atomic rename. Processes that had the replaced file open will just keep a handle to the old inode (now not linked to the file name anymore), that will go away as the last handle is closed. Meanwhile newly started processes will see and use the updated version.

This works on Windows too, because you can rename running executables.

The difference between the two is that on Linux a delete will remove the name from the namespace but leave open descriptors to the old inode; on Windows the name remains in the namespace until the last handle is closed. This means on Linux you could delete a file then write a new one while executing the old one, which doesn't work on Windows. But with atomic rename, this point is moot.

Note that if updating a running program was truly impossible, Windows Update wouldn't be able to update itself. Pushing the problem to some other lower level component doesn't solve it either (eg. smss can't update itself.)

Reply Parent Score: 4