Subject: Re: advice on upgrading to 1.2
To: Joel Klecker <jk@esperance.com>
From: Christopher R. Bowman <crb@glue.umd.edu>
List: port-mac68k
Date: 12/03/1996 13:34:49
>>Is there a way I can do a seperate completely clean install of 1.2 ON
>>THE SAME DISK as my 1.1? That is, w/out overwriting it? I have enough
>>disk space (I think) - 450+ MB free, but I'm not sure if the
>>partitioning will allow what I'm suggesting. Basically, all of the free
>>space is on the /usr (g) partition. Unfortunately, I don't have access
>>to another disk.
>Here's how I did it. I copied all the tarballs onto my /usr partition,
>booted single user and used the a command line similar to the following
>"cd /;tar xzpf /tmp{base12,misc12,text12,comp12,man12}.tar.gz --unlink",
>don't do this with etc12.tar.gz though(unless you want to wipe out your
>passwd file and your other settings). This will overwrite the 1.1 files
>with the 1.2 versions, booting single user will ensure that all files (Q:
>Does this update binaries currently in use(i.e. /bin/sh or /bin/csh)?) can
>be updated.

As I understand the unlink directive, it does do what you want.  It takes
the directory entry for a particular file out of the directory, note the
file can still be accessed via the inode, but a namespace lookup won't find
it.  This means that if, for instance, /bin/sh is running and it is it's
turn to be updated, the direcory /bin is rewritten so that the entry for sh
which has the inode of the old sh is removed.  Now the kernel and indeed
any process with an open file descriptor can still access the old sh file,
since file descriptors still point to the inode and the inode still exists
on disk, and the data blocks haven't been deallocated, and the inode still
points to them, BUT there is no longer an entry in the /bin directory that
points to the inode, thus no one else can open this particular file (unless
there was another hard link to it).  However now since the directory
doesn't contain an entry for sh, a process is free to write a new one, this
one will get a new inode since the old inode for sh is still in use, and
now any subesquent open of /bin/sh will get the new sh BUT old file
descriptors opened before the old sh was unlinked, still access the old sh
since the file descriptors point to inodes, and not directory entries.

Does this explain? Let me know if you want to know more.

---------
Christopher R. Bowman
crb@eng.umd.edu
My home page