by The Ghost » Fri, 06 Apr 2007 01:10:46
n comp.os.linux.advocacy, Freeride
< XXXX@XXXXX.COM >
wrote
on Wed, 04 Apr 2007 03:33:07 GMT
<T%EQh.115280$ XXXX@XXXXX.COM >:
Not every patch or install requires a reboot -- though
many will. There's a fundamental issue involved: inodes.
On Linux, one can do the equivalent of
tar xzf pkgfile.tgz
cp pkgfile/some/where/or/other/executable /usr/bin/executable.new
mv /usr/bin/executable.new /usr/bin/executable
privileges permitting (I don't know precisely how install
works, but it's something like this) and if 'executable'
is running somewhere, no harm, no foul, unless 'executable'
tries to dynamically load something incompatible with it
(because a version changed) or execute something which
has been moved (forking is OK, AFAIK).
This is because /usr/bin/executable, when executed, becomes
an inode internally, and one can rename /usr/bin/executable
or even delete the name without harming the inode (though
if one deletes the name the inode will be reclaimed when
the process terminates, absent hard links). One can
also rename a file; apart from a corner case where
"mv filea fileb" is trying to rename one file to another but
both are actually hardlinks to the same file, it's fairly
straightforward. [*]
Hard links with inodes are very trivial, requiring little
more than management of a use count. (This is why the
number in ls -ld . shows up; each directory has two entries,
namely '.' in its own list, and its name in its parent's.
All other files show '1' unless they're hardlink somewhere
else. If a directory contains subdirectories, the use count
will be 2 more than the number of subdirectories, because
each directory has a '..' backpointer as well. find uses
this to its advantage by default; -noleaf may be required
on certain filesystems such as NTFS that don't follow this
use counting methodology. However, it appears 'ls -ld /c'
returns a 1 in that case anyway, and find still finds the
subdirectories.)
Of course it's probably a good idea to restart the
service anyway, which will cause a momentary interruption
of service, but one needn't restart the entire system.
Windows might finally be waking up to this methodology,
though it's hard to say at this point.
(Inode numbers, FWIW, can be seen with 'ls -i'. They won't
mean a heck of a lot to the user, though a software
engineer can have a routine do a stat() or fstat() on two
pathnames, then compare the st_dev and st_ino fields of
the stat structure to see if they're referring to the same
file or directory. File systems without inodes, such as
vfat, hack it; vfat in particular uses the first cluster
number as an inode, IINM. Not sure what Linux vfat does
for empty files. NFS introduces its own peculiarities,
which I'd have to look up.)
On Windows, things get a little more interesting. I don't
know the details, but if a file is in use (i.e., being
executed), one cannot overwrite it, move it, delete it,
rename it, or rename over it. (One wouldn't want to
overwrite over a Linux executable in use either -- and in
fact Linux disallows it with a "Text file busy" error,
ETXTBSY, 26. HP/UX, once upon a time way back when,
allowed the overwrite, but killed processes later with a
"page I/O error". Presumably this has been changed by now.
No problem on Linux renaming it or renaming over it,
though.)
Windows Installers therefore have to kludge around this.
Presumably they stuff an autostart into th
