Restarts Revisited: Windows isn’t that different than UNIX

I’ve been meaning to follow up on my blog entry about the Restart Manager and reboots on the Windows platform in general. I saw a lot of incorrect conclusions being drawn from my blog entry. So, I want to quickly revisit the issue and hopefully clear up the confusion. Hopefully, this time I’ll communicate more clearly.

Jonathan Bastien-Filiatrault’s blog post goes right to the heart of the incorrect conclusion drawn by many. He states the following:

One thing that makes Unix in general not need this is that if a file is unlinked, as long as there are open file descriptors to this file, that file is not removed from disk (even if it cannot be referenced from the directory hierarchy) and the memory maps from an executable or library can be maintained.

I didn’t clearly note in my last blog entry that my experiments with Reid’s PowerBook proved to me that this is true. You can delete files even if they are in use on UNIX. That’s nice but it still doesn’t solve either of the two issues that are the real reason a reboot is required:

1. The old file is still running (i.e. you are still vulnerable to any security exploits)

2. New executions of the file get the updated version while the old executions of the file keep using the old file (i.e. you may have inter-/intra-process communication problems).

On Windows, replacing a file that is in use takes more steps (rename, replace, delete) than UNIX (delete, replace) but on either operating systems you need to stop the updated process for the update to truly take effect.

Jonathan also states:

When that file is unlinked, one can sneak a new library into place atomically.

I’m not sure what he means by "atomically" but unless the file system supports true ACID-like transactions then an "rm oldfile" "cp newfile oldfile" is not an atomic operation. The next version of the NT file system (shipping for the first time with Windows Vista, I believe) supports transactions such that "ren oldfile tempfile" "copy newfile oldfile" can actually be done atomically. But that is a conversation for a different day.

Anyway, I just wanted to be a bit more clear on the topic and note that fundamentally, file-in-use handling on the two operating systems aren’t really different and that the Restart Manager functionality would be useful on any operating system.

Comments (7)

  1. Philip says:


    you are perfectly right with your explanations about unix. Still, I do prefer the handling how it’s done in that operating system. Granted. You must reboot if you want that security update to be applied, but many times it’s not a security update you are deploying, but something else.

    And then this behaviour is incredibly useful.

    And if it’s no kernel component you are switching, the benefits get even more interesting.

    Say you are remotely updating the SSH daemon and you don’t have physical access to the machine.

    0) Backup the current installation

    1) Update the Files

    2) Restart the ssh-daemon (your current session will keep running the old code)

    3) Try to connect a new session. If it works, close the current session to terminate the last remaining old instance. if not, put the backup back in place.

    No reboots needed, no interruptions of your workflow.

    I do like that.

    But I also respect the windows-way of doing the thing and I personally think that the restart manager is a nice solution.


  2. To change a file atomically on a UNIX filesystem, you can do:

    ln oldfile oldfile.bak

    mv newfile oldfile

    with this, you can swap files atomically since the "relink" system call is atomic on the same filesystem. Anyway, keep up the great work.

  3. Jonathan, great point. I should have thought of that. That’s a simple way to do an automic single file update… and it wouldn’t work on Windows. Very nice.

    Now, if I only had more single file updates. <grin/>

  4. Phillip, AFAIK, all of those same steps would work on Windows. Of course, you’d have to add a Step .5) to "rename existing files out of the way" (which could *almost* be a backup mechanism). However, the rest of the scenario should work fine on Windows or UNIX.

    Assuming you don’t get bit by my issue #2 in the blog entry.

    IMHO, the problem on Windows is that too many services are deeply interconnected such that it is difficult to update one without having to stop another. So, while scenarios like yours above would work on Windows, the interdependencies between components makes it less likely "to just work".

  5. Rob, I also forgot, most (read all) services and applications on UNIX systems can be restarted without a reboot. This effectively re-links the in-memory executables as you mentionned. Even the super process init can be restarted (init q). On a GNU/Linux system, kernel updates are the only thing that require a mandatory reboot. Even then, I sometimes reboot a GNU/Linux system to check everything is in order and that it can boot properly and reach a fully-working state.

  6. Jonathan, yep, from what I’ve seen, UNIX is far easier to update piecemeal than Windows (something I’d like to see change in Windows). I suppose that makes the Restart Manager even more interesting on a Windows box. <smile/>

    Thanks for the great comments. Confirmed a lot of things I believed were true in UNIX but haven’t had time to investigate empirically.

  7. Adam says:

    For multi-file updates, if all the files are in their own directory, you can do atomic directory changes in a similar way:

    mv product product-2.3

    mv product-2.4 product

    rm -rf product-2.3

    If you need it to be _really_ atomic (i.e. no missing "product" directory between the "mv" commands) then if you originally set up the software with symlinks like so:

    mkdir product-2.3

    #[install stuff to product-2.3/]

    ln -s product-2.3 product

    then you can atomically update by atomically replacing the symlink:

    mkdir product-2.4

    #[install new version to product-2.4/]

    ln -sf product-2.4 product

    rm -rf product-2.3


    Of course, most unix programs don’t install to their own directory like this by default, but most can be made to. (See