Making rm undoable

Charles Hedrick hedrick at geneva.rutgers.edu
Mon Mar 27 10:51:42 AEST 1989


> soft links are
> meaningless because an NFS filesystem can be mounted anywhere and
> paths are therefore meaningless

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.

> 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.

File locking (actually System V record locking) has been present in
NFS on Suns since at least release 3.2.  It appears that the
implementation in 4.0.2 actually works.  (4.0.1 is the current
released version, but you can get 4.0.2 of the lock daemon from the
Sun software support people.)  NFS does manage to keep files that are
still open around.  Try the following:
   tail -f foo &
   rm foo
   ls .nfs*
You'll see that foo has been renamed to .nfsXXX.  Now if you kill the
tail, .nfsXXX will go away.  I'm not sure quite how that interacts
with statelessness.  It's possible that if you open a file, remove it,
and then crash before closing it, that the .nfsXXX file will stay on
the the file server.  I haven't looked at the code that carefully.

Despite all the comments about how NFS violates "Unix semantics",
we've not run into anything that failed across NFS, aside from bugs in
implementations.



More information about the Comp.unix.wizards mailing list