[447] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Craig_Everhart@transarc.com)
Mon Nov 18 13:17:15 1991
Date: Mon, 18 Nov 1991 12:04:00 -0500 (EST)
From: Craig_Everhart@transarc.com
To: Info-AFS@transarc.com, Wallace Colyer <wally+@andrew.cmu.edu>
Cc: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>,
In-Reply-To: <Qd9yQyW00WAqM0sSNY@andrew.cmu.edu>
Interesting problem in big directories. They clearly cost more
per-mount-point than big directories.
Excerpts from mail: 18-Nov-91 Re: AFS and NeXTs Wallace Colyer@andrew.cm
(1749+0)
> If you allow the sticky bit to return different information on a stat
> you have to have some way of setting the sticky bit as well since any
> operation on the mount point will currently only change the directory.
In the hack I suggested, or in at least its latest version, the sticky
bit is never set in persistent storage. The CM returns it to describe
an unevaluated mount point, which it doesn't evaluate in some
narrowly-defined set of circumstances (lstat(2) on a NeXT, for some set
of mount points). I believe that this is quite comparable to the
existing NeXT situation with the autonfsmounter, in that the sticky-bit
is set there only in the return structure from lstat(2).
Would it be better if the hack were to apply to any mount point?
Now that I'm speaking of this hack as it has a life of its own, let me
say that it doesn't; it is only a figment of our collective
imaginations, and decisions to act (e.g. implement) on those figments
don't fall to me.
Craig
