Freigeben über

Restarts Revisited: Windows isn't that different than UNIX

  • Artikel

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

  • Anonymous
    January 16, 2006
    The comment has been removed
  • Anonymous
    January 17, 2006
    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.
  • Anonymous
    January 17, 2006
    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/>
  • Anonymous
    January 17, 2006
    The comment has been removed
  • Anonymous
    January 17, 2006
    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.
  • Anonymous
    January 17, 2006
    The comment has been removed
  • Anonymous
    January 18, 2006
    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

    tada!

    Of course, most unix programs don't install to their own directory like this by default, but most can be made to. (See http://www.gobolinux.org/)