PDP-11 loader options

guy at rlgvax.UUCP guy at rlgvax.UUCP
Wed Jun 15 10:53:27 AEST 1983


Actually, the reason that you can't unlink an executable shared-text image
which is running is that if you did, there would be an inode out there
which would have no directory entry pointing to it; if the system crashed,
you would have an unreferenced inode out there and would have to say 'y' to
"fsck".

An inode is freed on disk by "ifree", which is only called from "iput", the
routine which removes a reference to an in-core inode.  If the link count on
the inode is zero, AND the reference count drops to zero, the inode is
freed by calling "ifree", setting the mode to 0, and freeing all the blocks.
However, for an active shared-text image, the reference count is NOT zero
until the last process using that image exits.  Therefore, the inode won't
be freed until the last process running it exits, and even if the file were
unlinked and a new file put in its place, there wouldn't be any real problems;
any processes executing the new file will get the new image, and the processes
which executed the old file will hold on to the old image.  This may cause
some confusion, but it won't wedge the system; and if you're careful about
installing new programs, or if you don't care, it's not a problem.  The
inability to remove running programs is a nuisance, and 4.1BSD disabled the
code that forbids it, which is very nice if you're working on a program that
other people are using and you want to stick a new one in and get rid of
the old one.

Note that the SAME "problem" mentioned with a crash up there can be caused
by opening a file, unlinking it, and holding it open; the file won't go away
until the last close, which decrements the reference count to zero.

The information about why unlinking executable images are forbidden comes from
a "highly regarded source" within Bell Labs.

		Guy Harris
		RLG Corporation
		{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy



More information about the Comp.unix.wizards mailing list