Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Making rm undoable
Message-ID: <10113@bloom-beacon.MIT.EDU>
Date: 26 Mar 89 05:31:56 GMT
References: <6805@phoenix.Princeton.EDU> <7360@phoenix.Princeton.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Distribution: usa
Organization: Massachusetts Institute of Technology
Lines: 49

In article <7360@phoenix.Princeton.EDU> bernsten@phoenix.Princeton.EDU
(Dan Bernstein) writes:

>For those who missed the original posting, I was proposing that rather
>than somehow convert every rm into an mv (unlink() into rename()), you
>could prepare beforehand for losing files by making an extra link
>somewhere safe with ln (link()). (That's what I meant to say, anyway.)
>After all, link() followed by unlink() is almost the same as to rename().

(I had missed the original posting.... Oh, well :-)

There are two problems with using link() or with keeping a file open
in order to prevent it from being lost.

Both of these mechanisms are useless under NFS (and possibly other
protocols, but I only know for sure about NFS) -- soft links are
meaningless because an NFS filesystem can be mounted anywhere and
paths are therefore meaningless, and hard links won't work very well
either because the trash directory has to be on the same filesystem as
the deleted file.  If I mount "/foo/bar/baz" from another machine onto
"/mnt" on my machine, and I use an rm that uses a link() call to
delete a file, where is it going to put the link?

Keeping a file open also does nothing under NFS -- there's no state,
so the NFS server doesn't realize that the file is open and it will go
away.  I hear that the next version of NFS supplies the capability to
do file locking, but I don't know if this includes keeping track of
busy files.

This discussion came up some time last year in comp.unix.wizards.  At
that point, I was working on a suite of file-deletion (and undeletion)
utilities for Project Athena.  That set of programs has been finished
and is going in the next Project Athena software release.  The
particular attractiveness of the "delete" program is that it can
exactly emulate the behavior of rm and rmdir if that is desired, with
the result that you can do a couple of aliases and then never realize
that you're using delete (unless you need to undelete something)!

If people are interested in getting the sources to the programs
(delete, undelete, expunge, purge, and lsdel), I can probably send
people sources (after I check with my boss and get a copy of the
copyright notice that has to appear at the top of each file :-).  It's
only been tested on BSD, but I assume that it will work with minimal
modification on other Unix platforms as well.

Jonathan Kamens			              USnail:
MIT Project Athena				410 Memorial Drive, No. 223F
jik@Athena.MIT.EDU				Cambridge, MA 02139-4318
Office: 617-253-4261			      Home: 617-225-8218