Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!emory!gatech!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.misc
Subject: Re: Protection from "rm *"
Message-ID: <1990Oct16.215634.23052@athena.mit.edu>
Date: 16 Oct 90 21:56:34 GMT
References: <1990Oct11.184004.9353@nntp-server.caltech.edu> <1100@bilver.UUCP> <4195@auspex.auspex.com> <4198@lib.tmc.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 36

In article <4198@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes:
|> OK...I give up. Why is not being able to remove a program in use a botch?

  When you delete a file that a process has open, the file is removed from the
filesystem, but the process which has it opened it continues to have access to
it until the file is closed (unless it's on a non-local filesystem such as
NFS, in which case things may get a bit more complicated :-).  If multiple
processes have the file open, they all continue to be able to use it until
they all close it.  The kernel removes the file from its directory, but
doesn't actually completely remove the file until there are no longer any
processes that have opened it.

  Binaries should be treated the same way.  There is no reason not to be able
to delete a file which is an executable image currently in use.  There *are*
reasons why you *should* be able to do so.  For example, if I want to install
a new version of a program without disturbing people using the old version,
the best way to do it is to delete the old version and then copy the new one
into place.  This way, people who are using the executable continue to get
use that executable when the kernel tries to swap in from it, but people who
run the program from that point on will get the new version.

  If I can't delete a running executable, I am left with two choices: (a) move
the file to a different name (e.g. "foo.old") and copy the new one into place,
or (b) copy the new binary on top of the old one.  The former choice is less
than optimal because I have to remember to go back and delete the ".old" file
later (and who knows, somebody may keep it running it all night, or for
several days, or whatever!), and the second choice is less than optimal
because after the new binary is copied on top of the old one, people will get
swap errors when the kernel tries to swap in from the (nonexistent) old
executable image.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710