Making rm undoable

[Jonathan I. Kamens]

In article <Mar.26.19.51.41.1989.8372 at geneva.rutgers.edu>
hedrick at geneva.rutgers.edu (Charles Hedrick) writes:
>
>There are two ways to make soft links work across NFS.  One is to use
>a mounting convention that gives the same path names on all systems.
>We often use /machinename as the top level directory, even on the
>machine itself.  So a link to /machine/usr/bin/foo works anywhere.
>The other is for all of your symbolic links to be relative.  E.g.  if
>you want /usr/bin/foo to be a link to /usr/ucb/bar, define the link as
>../ucb/bar.  If you want it to be a link to /bin/bar, define the link
>as ../../bin/bar.  This presupposes that you mount all file systems
>from a given system at the same point in the local file system, of
>course.

Both of these will work fine when you're in a relatively small system
and NFS is only exported to a small number of hosts.

However, when you have more than 1000 workstations and more machines
of other types, all of which can NFS mount nearly any directory off of
any fileserver on campus on any mount point, it stops being feasible
to force directories always to get mounted in the same place and
always at the same level from the root.  In fact, the capability to
mount in different locations is used a lot here at Athena.

Both of the points you made will help make links *more* reliable, but
none of them will make the links completely reliable, and (in my
opinion) that's what you need when you are going to be using the links
for file removal.

When we first started going through design reviews for delete et al, a
system of ".deleted" directories storing symbolic links to deleted
files was proposed.  However, as we talked more and more about it, it
degenerated into something like this: "When a file is deleted, it is
renamed from foo to .#foo so that it becomes invisible to the user and
will be cleaned up in the nightly filesystem sweeps after a few days.
Then, the delete program starts walking up the directory tree until it
encounters either (a) a directory named .deleted or (b) the top of the
filesystem (NFS or whatever); while doing this it keeps track of how
many levels up it's gone and all of the directories it's transversed
up in order to be able to do a link back to the deleted file.  If it
gets to the top of the filesystem and doesn't find a .deleted
directory, it tries to create one.  If it fails, it starts walking
back *down* the directory chain until it finds a directory in which it
can create a .deleted directory, coming, at worst, back to the
original directory from which it started.  By this point, it should
have been able to create a .deleted directory, and it makes a link in
that directory to the deleted file."

If you think about it, you'll realize that this is the only way to
guarantee that a link will be created when working with NFS, unless
you have all filesystems mounted on all machines at all times,
something which we most definitely do not.

So, as you can see there are certain things that are *not* feasible
with NFS in certain environments.

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

P.S. Oh, so that's what all those .nfsXXX files are from :-)