[429] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Craig_Everhart@transarc.com)
Fri Nov 15 15:38:16 1991
Date: Fri, 15 Nov 1991 13:12:42 -0500 (EST)
From: Craig_Everhart@transarc.com
To: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>
Cc: Wallace Colyer <wally+@andrew.cmu.edu>, reuss@ni.umd.edu,
In-Reply-To: <9111151700.AA13928@terminator.cc.umich.edu>
You might not need a special root.afs.next at all, if you invent some
convention like:
in the NeXT CM, when the CM comes across a cellular mount point and
hasn't ever referred to the cell, and the call is for an lstat() or
readlink(), don't traverse the mount point, but return a stat buffer
describing a symlink with the sticky bit on. In all other cases of
mount points in the NeXT CM, traverse the symlink.
Clearly, a few key programs on the NeXT have been modified to deal with
this /Net stuff, and won't stumble if they're presented with this
information. What I wonder about is all the other programs in the
universe, who expect that when lstat() says that there's a symlink, they
will be able to use readlink(2) to get all the information they need out
of that symlink.
Here's another set of problems. What would the NeXT CM return for
readlink(2) for such a mount point? It might well return an
apparently-garbage string (like ``#cs.cmu.edu:root.cell''), not usable
as a file name. Alternatively, somebody might have traversed the mount
point at some time between the lstat() and the readlink(), and so
readlink(2) might now believe that the target for the mount point is
``known,'' so readlink() would fail with something like EINVAL--target
not a symbolic link, but rather a directory.
Craig
