[431] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Michael T. Stolarchuk)
Fri Nov 15 16:23:58 1991
To: Craig_Everhart@transarc.com
Cc: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>,
In-Reply-To: Your message of "Fri, 15 Nov 91 13:12:42 EST."
Date: Fri, 15 Nov 91 13:40:12 -0500
From: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>
"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."
I'm stil holding on to the background FetchStatus performed on the
entry in /afs... even though it may cause extra GetTime requests
to those servers for a while... though we could cause those
remote connections to die a quicker death (depening on some
round trip time, which we will now have good values for)...
I'm not a big believer in making the 'fs lsmounts' visible as
symbolic links. I like the idea of using the sticky bit, but
I view this as a way to tell the CM to treat the mkmount differently;
providing local interpretation when no vcache stat entry is valid
for the mkmount. That also means something like 'fs' would have the
mechanism for setting and clearing the bit...
chdir-ing, or any direct use of the mkmount beyond stat would
be suspended till the backgroud FetchStatus was returned (ie
until the vcache stat entry was valid).
The hope is that the background daemons could fill the stat
entries before a process needed the true stat contents, and the
correct guess (via FetchStatus permission bits based on correct
viceid access) could be made to allow or not-allow the operation...
mts.
