Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!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: <1990Oct19.074149.8343@athena.mit.edu>
Date: 19 Oct 90 07:41:49 GMT
References: <1990Oct11.184004.9353@nntp-server.caltech.edu> <1100@bilver.UUCP> <4195@auspex.auspex.com> <4198@lib.tmc.edu> <1990Oct16.215634.23052@athena.mit.edu> <1990Oct18.152958.15635@eci386.uucp>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 34

In article <1990Oct18.152958.15635@eci386.uucp>, jmm@eci386.uucp (John Macdonald) writes:
|> If this is a frequently occurring activity, then there is a simple way of
|> getting choice (a) to work correctly.  Make a directory "old" in each bin
|> directory.  To destructively update foo, "mv foo old/rm$$", and then copy
|> in the new version.  Have a cron job that runs nightly that does
|> "find /bin/old /usr/bin/old <any others> -type f -print | xargs rm -f".
|> It will keep trying until it can actually do the job.  In times of heavy
|> program upgrades, the cron job could be tried hourly if the old versions
|> are cluttering up the disk.  Alternately, the script that does moves old
|> stuff to the old directory could get fancy - remove if possible before
|> moving to old, and try to clean out the old directory too in case something
|> is now removable.

  So, if we don't want "old" directories all over the place, then every
partition on the system has to know have an old directory somewhere on it (so
the "mv" can occur without copying across partitions), and every makefile that
does installations has to know what directory it's supposed to move the old
binary into when installing.

  The makefiles can be simpler if every directory has an old subdirectory, but
that means that there are "old" directories scattered all over the system
cluttering it up.

  Alternatively, we could just fix the System V kernel so it does the right
thing and allows you to unlink the executable.  Why are you fighting so hard
to figure out obviously suboptimal solutions, when the correct solution is
already clear (and is trivial to implement, and in fact is already implemented
in SVR4 and in most (if not all) BSD-based systems)?

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