12 ms·

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 c

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.
- tialaramex 9y ago
  Yes, in principle what you've said about the Unix approach here is correct, if you upgrade one half of a system and not the other half and now they're talking different protocols, that might not work. But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability, you've made a system that's deliberately not very robust, unless it's very, very tightly integrated (e.g. two sub-routines inside the same running program) the cost savings had better be _enormous_ or what you're doing is just amplifying a problem and giving it to somebody else, like "solving" a city's waste problem by just dumping all the raw sewage into a neighbouring city's rivers. Now, the "you can't delete things because then the disk space is unreachable" argument makes plenty of sense for, say, FAT, a filesystem from the 1980s. But (present year argument) this is 2018. Everybody's main file systems are journalled. Sure enough, both systems _can_ write a record to the journal which will cause the blocks to be freed on replay and then remove that journal entry if the blocks actually get freed up before then. The difference is that Windows doesn't bother doing this.
  - mehrdadn 9y ago
    Aaaaaand here comes the Linux defending! OK... > But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability It's weird that you're blaming my operating system's problems on me. "My system" is something a ton of other people wrote, and this is the case for pretty much every user of every OS. I'm not engineering anything into (or out of) my system so I don't get the "you've made a system that [basically, sucks]" comments. > [other arguments] I wasn't trying to go down this rabbit hole of Linux-bashing (I was just trying to present it as as objective of a flexibility-vs.-reliability trade-off as I could), but given the barrage of comments I've been receiving: I don't know about you, but it happens more often than I would like that I update Linux (Ubuntu) and, lo and behold, I can't really use any programs until I reboot. Sometimes the window rendering gets messed up, sometimes I get random error pop-ups, sometimes stuff just doesn't run. I don't get why it happens in every instance, and there might be lots of different reasons in different instances. IPC mismatch is my best guess for a significant fraction of the incidents. All I know is it happens and it's less stable than what you (or I) would hope or expect. Yet from everyone's comments here I'm guessing I must be the only one who encounters this. Sad for me, but I'm happy for you guys I guess.
sclangdon 9y ago
> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it You can rename a file when it's open. And once it's renamed, you can delete it.
quietbritishjim 9y ago
This doesn't fully explain why a reboot is not required on Linux. If a *nix operating system updates sysfile1.so and sysfile2.so in the way you describe, then there will be some time where the filename sysfile1.so refers to the new version of that file while sysfile2.so refers to the old version. A program that is started in this brief window will get mixed versions of these libraries. It is unlikely that all combinations of versions of libraries have been tested together, so you could end up running with untested and possibly incompatible versions of libraries.
- snuxoll 9y ago
  This generally should never happen, Linux distributions don’t wholesale replace shared objects with ABI incompatible versions - soname’s exist to protect against this very issue.
- beagle3 9y ago
  > This doesn't fully explain why a reboot is not required on Linux. Of course there is a theoretical possibility that this will happen; however, in practice, updates (especially security updates) on Linux happen with ABI compatible libraries. E.g. on debian/ubuntu apt-get update && apt-get upgrade Will generally only do ABI compatible updates, without installing additional packages (you need 'dist-upgrade' or 'full-upgrade' for that). Some updates will go as far as to prevent a program restart while updating (by temporarily making the executable unavailable). Firefox on Ubuntu is an outlier - an update will replace it with one that isn't ABI compatible. It detects this and encourages you to restart it. All in all, it's not that a reboot is never required for linux theoretically - it is that practically, you MUST reboot only for a kernel update, and may occasionally need to restart other programs that have been updated (but are rarely forced too).
- CJefferson 9y ago
  I had a program with a rarely reported bug that turned out to be lazy loading of .so files that was this bug. Switched to eager loading and it went away.
GirlsCanCode 9y ago
This is completely untrue. How much does Tim pay you to spread these lies?
Razengan 9y ago
Heck, on Windows I couldn't even rename audio/video files when playing them in an app, but I can on macOS, without anything crashing (except some stubborn Windows-logic apps like VLC which will fail to replay something from its playlist that has since been renamed, but at least on macOS it will still allow you to rename or move the files while they're being played.) It's small details like these that make so much difference in daily convenience.
- ksk 9y ago
  I think a general purpose UX should err on the side of "make it difficult for non-technical users to make mistakes" Renaming/Deleting files in use is one of those things that us nerds like to complain about, but it makes sense when you think of an accountant that has an open spreadsheet and accidentally deletes a folder with that file. For average non-technical people (on any OS) I would say it makes sense to block that file from being deleted.
  - rubatuga 9y ago
    I see you’ve never actually experienced it? It is actually more intuitive for the average user, as the file name is updated across every application immediately. In fact, you can actually change the file name from the top of the window directly.
    - ksk 9y ago
      How does the user know that the file is open? Also, Is it consistent across network folder renames too?
    - nomel 9y ago
      I have experienced this many times in MacOS after deleting a file/folder and replacing it with some other version, like one downloaded from an email. After a while, I realize that I'm working from ~/.Trash and the attachment I just sent didn't include the changes I had been making for the last hour. I've had this happen in bash also, where I modify some script in an external editor then try to run it, only to realize that I'm running from the trash, even though the bash prompt naively tells me I'm in ~/SomethingNotTrashFolder. Intuitive would be "Hey, this file you're working on was just moved to the trash. There's a 99.9999% chance you don't want to do this." rather than hoping the filepath is visible, and noticed by dumb chance, in the title bar, since not many people periodically glance at the file they have open to verify it's still the file they want open.
ainiriand 9y ago
Maybe this is also why 'rm -rf /' is so effective in destroying your system, isn't it?
aussie1233 9y ago
That is incorrect. It just depends on Windows how you call the Win32 API and what parameters you specify. Many options there - in the end it's just an object in the NT kernel space.
boznz 9y ago
> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; I am not sure about deletion, but one of my programs has been using the ability to rename itself to do updates for the last 15 years.
yuhong 9y ago
What is really irritating is when for example an update that only changes mshtml.dll requires a reboot because a program unnecessarily depends on it. These are not as common as it used to be though.
nullymcnull 9y ago
> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it It's simple for any application to open a file in Windows such that it will allow a rename or delete while open - set the FILE_SHARE_DELETE bit on the dwShareMode arg of the win32 CreateFile() function. In .NET, the same behaviour is exposed by File.Open / FileShare.Delete.

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.

tialaramex 9y ago
Yes, in principle what you've said about the Unix approach here is correct, if you upgrade one half of a system and not the other half and now they're talking different protocols, that might not work. But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability, you've made a system that's deliberately not very robust, unless it's very, very tightly integrated (e.g. two sub-routines inside the same running program) the cost savings had better be _enormous_ or what you're doing is just amplifying a problem and giving it to somebody else, like "solving" a city's waste problem by just dumping all the raw sewage into a neighbouring city's rivers. Now, the "you can't delete things because then the disk space is unreachable" argument makes plenty of sense for, say, FAT, a filesystem from the 1980s. But (present year argument) this is 2018. Everybody's main file systems are journalled. Sure enough, both systems _can_ write a record to the journal which will cause the blocks to be freed on replay and then remove that journal entry if the blocks actually get freed up before then. The difference is that Windows doesn't bother doing this.
- mehrdadn 9y ago
  Aaaaaand here comes the Linux defending! OK... > But keep in mind that if your system can't cope with this what you've done there is engineer in unreliability It's weird that you're blaming my operating system's problems on me. "My system" is something a ton of other people wrote, and this is the case for pretty much every user of every OS. I'm not engineering anything into (or out of) my system so I don't get the "you've made a system that [basically, sucks]" comments. > [other arguments] I wasn't trying to go down this rabbit hole of Linux-bashing (I was just trying to present it as as objective of a flexibility-vs.-reliability trade-off as I could), but given the barrage of comments I've been receiving: I don't know about you, but it happens more often than I would like that I update Linux (Ubuntu) and, lo and behold, I can't really use any programs until I reboot. Sometimes the window rendering gets messed up, sometimes I get random error pop-ups, sometimes stuff just doesn't run. I don't get why it happens in every instance, and there might be lots of different reasons in different instances. IPC mismatch is my best guess for a significant fraction of the incidents. All I know is it happens and it's less stable than what you (or I) would hope or expect. Yet from everyone's comments here I'm guessing I must be the only one who encounters this. Sad for me, but I'm happy for you guys I guess.

sclangdon 9y ago

> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it You can rename a file when it's open. And once it's renamed, you can delete it.

quietbritishjim 9y ago

This doesn't fully explain why a reboot is not required on Linux. If a *nix operating system updates sysfile1.so and sysfile2.so in the way you describe, then there will be some time where the filename sysfile1.so refers to the new version of that file while sysfile2.so refers to the old version. A program that is started in this brief window will get mixed versions of these libraries. It is unlikely that all combinations of versions of libraries have been tested together, so you could end up running with untested and possibly incompatible versions of libraries.

snuxoll 9y ago
This generally should never happen, Linux distributions don’t wholesale replace shared objects with ABI incompatible versions - soname’s exist to protect against this very issue.
beagle3 9y ago
> This doesn't fully explain why a reboot is not required on Linux. Of course there is a theoretical possibility that this will happen; however, in practice, updates (especially security updates) on Linux happen with ABI compatible libraries. E.g. on debian/ubuntu apt-get update && apt-get upgrade Will generally only do ABI compatible updates, without installing additional packages (you need 'dist-upgrade' or 'full-upgrade' for that). Some updates will go as far as to prevent a program restart while updating (by temporarily making the executable unavailable). Firefox on Ubuntu is an outlier - an update will replace it with one that isn't ABI compatible. It detects this and encourages you to restart it. All in all, it's not that a reboot is never required for linux theoretically - it is that practically, you MUST reboot only for a kernel update, and may occasionally need to restart other programs that have been updated (but are rarely forced too).
CJefferson 9y ago
I had a program with a rarely reported bug that turned out to be lazy loading of .so files that was this bug. Switched to eager loading and it went away.

GirlsCanCode 9y ago

This is completely untrue. How much does Tim pay you to spread these lies?

Razengan 9y ago

Heck, on Windows I couldn't even rename audio/video files when playing them in an app, but I can on macOS, without anything crashing (except some stubborn Windows-logic apps like VLC which will fail to replay something from its playlist that has since been renamed, but at least on macOS it will still allow you to rename or move the files while they're being played.) It's small details like these that make so much difference in daily convenience.

ksk 9y ago
I think a general purpose UX should err on the side of "make it difficult for non-technical users to make mistakes" Renaming/Deleting files in use is one of those things that us nerds like to complain about, but it makes sense when you think of an accountant that has an open spreadsheet and accidentally deletes a folder with that file. For average non-technical people (on any OS) I would say it makes sense to block that file from being deleted.
- rubatuga 9y ago
  I see you’ve never actually experienced it? It is actually more intuitive for the average user, as the file name is updated across every application immediately. In fact, you can actually change the file name from the top of the window directly.
  - ksk 9y ago
    How does the user know that the file is open? Also, Is it consistent across network folder renames too?
  - nomel 9y ago
    I have experienced this many times in MacOS after deleting a file/folder and replacing it with some other version, like one downloaded from an email. After a while, I realize that I'm working from ~/.Trash and the attachment I just sent didn't include the changes I had been making for the last hour. I've had this happen in bash also, where I modify some script in an external editor then try to run it, only to realize that I'm running from the trash, even though the bash prompt naively tells me I'm in ~/SomethingNotTrashFolder. Intuitive would be "Hey, this file you're working on was just moved to the trash. There's a 99.9999% chance you don't want to do this." rather than hoping the filepath is visible, and noticed by dumb chance, in the title bar, since not many people periodically glance at the file they have open to verify it's still the file they want open.

ainiriand 9y ago

Maybe this is also why 'rm -rf /' is so effective in destroying your system, isn't it?

aussie1233 9y ago

That is incorrect. It just depends on Windows how you call the Win32 API and what parameters you specify. Many options there - in the end it's just an object in the NT kernel space.

boznz 9y ago

> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it; I am not sure about deletion, but one of my programs has been using the ability to rename itself to do updates for the last 15 years.

yuhong 9y ago

What is really irritating is when for example an update that only changes mshtml.dll requires a reboot because a program unnecessarily depends on it. These are not as common as it used to be though.

nullymcnull 9y ago

> On Windows, once the file is open, it is that filename that is open; You can't rename or delete it It's simple for any application to open a file in Windows such that it will allow a rename or delete while open - set the FILE_SHARE_DELETE bit on the dwShareMode arg of the win32 CreateFile() function. In .NET, the same behaviour is exposed by File.Open / FileShare.Delete.