[445] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Craig_Everhart@transarc.com)
Mon Nov 18 11:15:09 1991
Date: Mon, 18 Nov 1991 10:05:46 -0500 (EST)
From: Craig_Everhart@transarc.com
To: Cal_Thixton@next.com
Cc: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>,
In-Reply-To: <9111152333.AA23440@dorothy.NeXT.COM>
Cal, I'm not sure you're dealing with this in an even-handed way. As
Karl Reuss points out, Workspace (and NeXT's 'ls -F') cooperates with
the auto-nfs-mounter so that listing entries under /Net don't cause
network traffic. I'm not interested in the marketing issues, but in the
technical ones.
I had asked for some specific technical information. I specifically
asked for some clarification on how this cooperation happens, so that
perhaps AFS could try to cooperate also. (``What attribute is Workspace
looking for in printing ``(automount)'' that it couldn't, or can't,
print for names under /afs?'') Karl has described how he believes the
cooperation happens (an lstat(2) returns a symlink with the ``sticky''
bit on in the mode field). Is this the case?
I believe that any solution for the NeXT-browser problem that results in
``pwd'' doing different things on NeXT platforms and non-NeXT platforms,
or on NeXT machines installed in different cells, is fatally flawed,
from a technical standpoint. To that end, I haven't yet seen any better
suggestion than the one I made, wherein a cellular mount point to a cell
not yet referenced is treated by lstat(2) as a symlink with the
``sticky'' bit, on NeXT implementations of the CM.
AFS on the NeXT could adopt the same strategy as the auto-nfs-mounter
when it comes to doing something for readlink(2). If, as Karl says,
readlink(2) would cause an evaluation of the symlink (and an error
return from readlink(2) itself), AFS could do the same thing.
To Mike Stolarchuk's concern about mount points: I believe that AFS
mount points and their targets have separate vcache entries. The AFS CM
convention is to evaluate the mount point every time it's referenced,
but what I'm suggesting here is bypassing that convention, on one
implementation, in one special case. That is, I don't think that
there's a pervasive problem with lying about the vcache state. And my
proposal, at least, deals only with cross-cell mount points, not
same-cell mount points. (Most cross-cell mount points reside under /afs
itself.)
Craig
