11 ms·

Speaking of which, why do so many things require reboot to update on Windows?

gaius 9y ago
To force a reinitialisation of all security contexts. Same reason that many websites make you log in again immediately after changing your password (which interestingly Windows doesn’t) Historically (Windows 95 and earlier) reboots were required to reload DLLs and so on but that’s not really true anymore. Still a lot of installers and docs say to reboot when it’s not really necessary as a holdover from then
- lucb1e 9y ago
  I was under the impression that the reason is what u/beagle3 mentions (in a sibling comment to yours): open system files. I'm curious to see your comment on what he describes, as what you mention (reloading some security context) does not seem to be the whole truth. That websites make one log in again after changing your password has nothing to do with this.
  - gaius 9y ago
    That websites make one log in again after changing your password has nothing to do with this. No it is exactly the same principle: something has changed therefore invalidate all existing contexts. Far less error prone than trying to recompute them, what happens e.g. if a resource has already been accessed in a context that is now denied? Security 101.
    - lucb1e 9y ago
      I don't see how changing my password changes a "security context". I don't suddenly get more or fewer permissions. As for logging other places out, that's a design choice. People change password either because they routinely change theirs (they either need to or choose to), or because of a (suspected) compromise. In the latter case you'll probably want to log everyone else out (though, who says you're logging out the attacker and not the legitimate user?) and in the former case you shouldn't (otherwise changing your password becomes annoying and avoided). The interface for changing the password could have a "log out all sessions" checkbox or it could just be a feature separate from changing your password. No, it's not as simple as you put it. No need to condescendingly pass it off as "security 101".
beagle3 9y ago
There is a very fundamental difference between how Unix and Windows view open files: On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; Therefore, if you want to replace a DLL (or any other file) that is in use, you have to kill any program that uses it before you can do that; And if it's a fundamental library everything uses (USER32.DLL COMCTL.DLL etc), the only effectively reliable way to do that is reboot. On Unix, once you have a handle=descriptor of the file, the name is irrelevant; You can delete or rename the file, The descriptor still refers to the file that was opened. Thus, you can just replace any system file; Existing programs will keep using the old one until they close/restart, new programs will get the new file. What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. Most upgrade procedures will restart relevant daemons or user programs, or notify that you should, (e.g. Debian and Ubuntu do). You always need a reboot to upgrade a kernel (kernel-splice and friends not withstanding), but otherwise it is enough in Unixes to restart the affected programs.
- mehrdadn 9y ago
  > On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; This is wrong... there's no clear-cut thing like the "file name" or "file stream" that you can specify as "in-use". It depends on the specifics of how the file is opened; often you can rename but not delete files that are open. Some (but AFAIK not all) in-use DLLs are like this. They can be renamed but not deleted. And then there's FILE_SHARE_DELETE which allows deletion, but then the handle starts returning errors when the file is deleted (as opposed to keeping the file "alive"). To make it even more confusing, you can pretty much always even create hardlinks to files that are "in use", but once you do that the new name cannot be deleted unless the old name can also be deleted (i.e. they follow the same rules). This should also make it clear that it's not the "name" that's in use, but the "actual file" (whatever that means... on NTFS I'd suppose it corresponds to the "file record" in the MFT). The rule that Windows always abides by is that everything that takes up space on the disk must be reachable via some path. So you can't delete in-use files entirely because then they would be allocated disk space but unreachable via any path. > What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. What I expect it also means is that you'll get inconsistencies when doing inter-process communication, since they'll be using different libraries with potential mismatches. Is this correct? Because it seems to me that the Windows method might be less flexible but is likely to be more stable, since there's a single coherent global view of the file system at any given time.
faragon 9y ago
The main reason is that in Windows executable files and dynamic libraries (.exe and .dll) are locked while a process is using them, while in other systems, e.g. Linux, you can delete them from disk. The only absolute need for reboot should be an OS kernel update (there are cases where a kernel could be updated/patched without a reboot).
pjc50 9y ago
Windows executables are opened with mandatory exclusive locking. So you can't overwrite a program or its DLLs while any instances of it are running. If a DLL is widely used, that makes it essentially impossible to update while the system is in use. There is a registry key which allows an update to schedule a set of rename operations on boot to drop in replacement file(s). https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/27/are-there-pending-operations-waiting-for-a-reboot/ https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/2...
- mehrdadn 9y ago
  > Windows executables are opened with mandatory exclusive locking. So you can't overwrite a program or its DLLs while any instances of it are running. This is not always correct; see: https://news.ycombinator.com/item?id=16256483 https://news.ycombinator.com/item?id=16256483
Shivetya 9y ago
I used to joke that Windows was alone in this issue, my work laptop being a prime example, but even Apple tends to towards reboots more often than not and especially as of late. Fortunately both can do it during slow periods; as in over night; and make updates nearly invisible to users.
vetinari 9y ago
> Speaking of which, why do so many things require reboot to update on Windows? We are getting there on Linux too - with atomic or image based updates of the underlying system. On servers you will (or already) have A/B partitions (or ostrees), on mobiles and IoT too, some desktops (looking at Fedora) also prefer reboot-update-reboot cycle, to prevent things like killing X while doing your update and leaving your machine in inconsistent state. macOS also does system updates with reboot, for the same reasons.
- Aissen 9y ago
  It's a miracle that reboot-less updates mostly work in Linux. You need to restart services, etc. to make sure they have the latest libs. Gnome3+systemd does that now: https://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/ https://blogs.gnome.org/hughsie/2012/06/04/offline-os-update... https://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ https://www.freedesktop.org/wiki/Software/systemd/SystemUpda... https://fedoraproject.org/wiki/Features/OfflineSystemUpdates https://fedoraproject.org/wiki/Features/OfflineSystemUpdates It's still much faster than a Windows update (at least on my SSD system).
- garblegarble 9y ago
  >macOS also does system updates with reboot, for the same reasons. And speaking from experience, the recent macOS way of applying an update is absolutely insane - on my Macbook Pro (with the stock SSD with 3GB/sec read and 2GB/sec of write) a small system update can take 10+ minutes to install
josteink 9y ago
> Speaking of which, why do so many things require reboot to update on Windows? Can't speak for everyone else, but Windows fully supports shared file-access which prevents the kind of file-locks which causes reboot requirements. The problem is that the default file-share permissions in the common Windows APIs (unless you want to get verbose in your code) is that the opening process demands exclusive access and locking to the underlying file for the lifetime of that file-handle. So unless the programmer takes the time to research that 1. these file-share permissions exists, 2. which permissions are appropriate for the use-cases they have in their code, and 3. how to apply these more lenient permissions in their code... Unless all that, you get Windows programs which creates exclusive file-locks, which again causes reboot-requirements upon upgrades. Not surprising really. In Linux/UNIX, the default seems to be the other way around: Full-sharing, unless locked down, and people seem prepared to write defensive code to lock-down only upon need, or have code prepare for worst-case scenarios.
Momquist 9y ago
I think a better question would be: why does Windows need multiple successive reboots? Too often my experience can be resumed as: update-reboot-reboot-update continuing-reboot... ad nauseam. At least on *nix, even when you need a reboot, once is enough.
jameshart 9y ago
So that's a fine question to ask, and you've received many fascinating answers, but can I just suggest that this case - that is, applying patches that relate to the security of your processor cache - is a very fine reason for requiring a reboot, since it will ensure that your processor cache starts out fresh and all behaviors that cause data to be placed there are correctly following the patched behavior.

To force a reinitialisation of all security contexts. Same reason that many websites make you log in again immediately after changing your password (which interestingly Windows doesn’t) Historically (Windows 95 and earlier) reboots were required to reload DLLs and so on but that’s not really true anymore. Still a lot of installers and docs say to reboot when it’s not really necessary as a holdover from then

lucb1e 9y ago
I was under the impression that the reason is what u/beagle3 mentions (in a sibling comment to yours): open system files. I'm curious to see your comment on what he describes, as what you mention (reloading some security context) does not seem to be the whole truth. That websites make one log in again after changing your password has nothing to do with this.
- gaius 9y ago
  That websites make one log in again after changing your password has nothing to do with this. No it is exactly the same principle: something has changed therefore invalidate all existing contexts. Far less error prone than trying to recompute them, what happens e.g. if a resource has already been accessed in a context that is now denied? Security 101.
  - lucb1e 9y ago
    I don't see how changing my password changes a "security context". I don't suddenly get more or fewer permissions. As for logging other places out, that's a design choice. People change password either because they routinely change theirs (they either need to or choose to), or because of a (suspected) compromise. In the latter case you'll probably want to log everyone else out (though, who says you're logging out the attacker and not the legitimate user?) and in the former case you shouldn't (otherwise changing your password becomes annoying and avoided). The interface for changing the password could have a "log out all sessions" checkbox or it could just be a feature separate from changing your password. No, it's not as simple as you put it. No need to condescendingly pass it off as "security 101".

beagle3 9y ago

There is a very fundamental difference between how Unix and Windows view open files: On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; Therefore, if you want to replace a DLL (or any other file) that is in use, you have to kill any program that uses it before you can do that; And if it's a fundamental library everything uses (USER32.DLL COMCTL.DLL etc), the only effectively reliable way to do that is reboot. On Unix, once you have a handle=descriptor of the file, the name is irrelevant; You can delete or rename the file, The descriptor still refers to the file that was opened. Thus, you can just replace any system file; Existing programs will keep using the old one until they close/restart, new programs will get the new file. What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. Most upgrade procedures will restart relevant daemons or user programs, or notify that you should, (e.g. Debian and Ubuntu do). You always need a reboot to upgrade a kernel (kernel-splice and friends not withstanding), but otherwise it is enough in Unixes to restart the affected programs.

mehrdadn 9y ago
> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; This is wrong... there's no clear-cut thing like the "file name" or "file stream" that you can specify as "in-use". It depends on the specifics of how the file is opened; often you can rename but not delete files that are open. Some (but AFAIK not all) in-use DLLs are like this. They can be renamed but not deleted. And then there's FILE_SHARE_DELETE which allows deletion, but then the handle starts returning errors when the file is deleted (as opposed to keeping the file "alive"). To make it even more confusing, you can pretty much always even create hardlinks to files that are "in use", but once you do that the new name cannot be deleted unless the old name can also be deleted (i.e. they follow the same rules). This should also make it clear that it's not the "name" that's in use, but the "actual file" (whatever that means... on NTFS I'd suppose it corresponds to the "file record" in the MFT). The rule that Windows always abides by is that everything that takes up space on the disk must be reachable via some path. So you can't delete in-use files entirely because then they would be allocated disk space but unreachable via any path. > What this means is, that even though you don't NEED to restart anything for most upgrades in Unix/Linux, you're still running the old version until you restart the program that uses it. What I expect it also means is that you'll get inconsistencies when doing inter-process communication, since they'll be using different libraries with potential mismatches. Is this correct? Because it seems to me that the Windows method might be less flexible but is likely to be more stable, since there's a single coherent global view of the file system at any given time.

faragon 9y ago

The main reason is that in Windows executable files and dynamic libraries (.exe and .dll) are locked while a process is using them, while in other systems, e.g. Linux, you can delete them from disk. The only absolute need for reboot should be an OS kernel update (there are cases where a kernel could be updated/patched without a reboot).

pjc50 9y ago

Windows executables are opened with mandatory exclusive locking. So you can't overwrite a program or its DLLs while any instances of it are running. If a DLL is widely used, that makes it essentially impossible to update while the system is in use. There is a registry key which allows an update to schedule a set of rename operations on boot to drop in replacement file(s). https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/27/are-there-pending-operations-waiting-for-a-reboot/ https://blogs.technet.microsoft.com/brad_rutkowski/2007/06/2...

mehrdadn 9y ago
> Windows executables are opened with mandatory exclusive locking. So you can't overwrite a program or its DLLs while any instances of it are running. This is not always correct; see: https://news.ycombinator.com/item?id=16256483 https://news.ycombinator.com/item?id=16256483

Shivetya 9y ago

I used to joke that Windows was alone in this issue, my work laptop being a prime example, but even Apple tends to towards reboots more often than not and especially as of late. Fortunately both can do it during slow periods; as in over night; and make updates nearly invisible to users.

vetinari 9y ago

> Speaking of which, why do so many things require reboot to update on Windows? We are getting there on Linux too - with atomic or image based updates of the underlying system. On servers you will (or already) have A/B partitions (or ostrees), on mobiles and IoT too, some desktops (looking at Fedora) also prefer reboot-update-reboot cycle, to prevent things like killing X while doing your update and leaving your machine in inconsistent state. macOS also does system updates with reboot, for the same reasons.

Aissen 9y ago
It's a miracle that reboot-less updates mostly work in Linux. You need to restart services, etc. to make sure they have the latest libs. Gnome3+systemd does that now: https://blogs.gnome.org/hughsie/2012/06/04/offline-os-updates-looking-forward-to-gnome-3-6/ https://blogs.gnome.org/hughsie/2012/06/04/offline-os-update... https://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ https://www.freedesktop.org/wiki/Software/systemd/SystemUpda... https://fedoraproject.org/wiki/Features/OfflineSystemUpdates https://fedoraproject.org/wiki/Features/OfflineSystemUpdates It's still much faster than a Windows update (at least on my SSD system).
garblegarble 9y ago
>macOS also does system updates with reboot, for the same reasons. And speaking from experience, the recent macOS way of applying an update is absolutely insane - on my Macbook Pro (with the stock SSD with 3GB/sec read and 2GB/sec of write) a small system update can take 10+ minutes to install

josteink 9y ago

> Speaking of which, why do so many things require reboot to update on Windows? Can't speak for everyone else, but Windows fully supports shared file-access which prevents the kind of file-locks which causes reboot requirements. The problem is that the default file-share permissions in the common Windows APIs (unless you want to get verbose in your code) is that the opening process demands exclusive access and locking to the underlying file for the lifetime of that file-handle. So unless the programmer takes the time to research that 1. these file-share permissions exists, 2. which permissions are appropriate for the use-cases they have in their code, and 3. how to apply these more lenient permissions in their code... Unless all that, you get Windows programs which creates exclusive file-locks, which again causes reboot-requirements upon upgrades. Not surprising really. In Linux/UNIX, the default seems to be the other way around: Full-sharing, unless locked down, and people seem prepared to write defensive code to lock-down only upon need, or have code prepare for worst-case scenarios.

Momquist 9y ago

I think a better question would be: why does Windows need multiple successive reboots? Too often my experience can be resumed as: update-reboot-reboot-update continuing-reboot... ad nauseam. At least on *nix, even when you need a reboot, once is enough.

jameshart 9y ago

So that's a fine question to ask, and you've received many fascinating answers, but can I just suggest that this case - that is, applying patches that relate to the security of your processor cache - is a very fine reason for requiring a reboot, since it will ensure that your processor cache starts out fresh and all behaviors that cause data to be placed there are correctly following the patched behavior.