[vetinari]

Windows cannot delete/replace files, that are open. That's the cause of most reboots, it will replace them before services or apps that use them start again.

Not that I'm apologizing it's behavior - it was a design decision that Windows team made in the past, when it was deemed not important and worth reduction in complexity. Now just it comes and bites them back.

[ksk]

>Windows cannot delete/replace files, that are open.

Not exactly. Its up to the application which opens files to control whether the file can be modified externally. It can do this in two ways. (1) Open the file in some FILE_SHARE_* mode and let the OS sort it out. (2) use opportunistic locks that will detect external access and then let the app decide how to react - anti-virus programs use this when they are scanning files.

>That's the cause of most reboots, it will replace them before services or apps that use them start again.

Actually the cause for reboots is much more mundane. Files replaced on disks means new programs using those files get the new version, however, processes which are already running keep using the older version in memory and are thus open to being exploited by bugs that are already patched.

On servers, things are a bit different. To prevent downtime you can 'hotpatch' the update and thus avoid the reboot.

[AaronFriel]

Linux doesn't solve the problem either, with the ability to replace open files. It just means you run into potential compatibility issues if you modify a shared lib and then two processes try to perform IPC that might rely on false assumptions (I believe this is exceedingly rare in practice) and to update kernel components, long-lived services you still need to restart them.

You can perform hot updates to a system but it can be complex and there are a number of restrictions on the types of updates that can be done.