[cryptonector]

In-place OS updates can be racy. Some updates require rebooting because they involve kernel changes that can't be applied to a running kernel. Then there's the WIN32 mandatory file locks issues, which prevent updates / replacement of files that apps are using.

But if Windows had anything like ZFS, they could apply updates on a fork of a dataset and then reboot very quickly into that dataset. That is the right way to do updates in general, at the price of always having to reboot, but you can do a mix of in-place updates when those don't require reboots and any races are safe, and ZFS-style updates otherwise.

[MrStonedOne]

> Then there's the WIN32 mandatory file locks issues, which prevent updates / replacement of files that apps are using.

I should point out that this is not actually a blocker, if somebody at windows actually gave a fuck they could abuse winsxs to do blue/green symlinks to get around the file lock issue. Meaning the update could happen in the background and take effect next boot without anything needing to happen at boot time. Most could be done by just restarting the proper system service.

Its just microsoft has decided not to give a fuck. Rather then work on why people want to deferrer and delay updates, they have decided... well, whats that meme? "no its the kids who are wrong".

[userbinator]

Even in the Win9x days, you could always rename a binary that was in use and copy the new one in its place, at which point newly spawned processes will use the new one while old processes continue to be unaffected.

Quite frankly I find the Linux/Unix-style behaviour of being able to delete/overwrite an in-use file a bit disconcerting, but that might just be because I'm more used to the Windows way.