finding NFS dirs in csh?

[David Robinson]

In article <33 at winchester.UUCP>, djl at winchester.UUCP (Dan Levin) writes:
> In article <10398 at sun.uucp>, guy at sun.uucp (Guy Harris) writes:
> > DIRECTORIES AREN'T FILES!!!!!!!!  They may happen to be implemented on UNIX
> > in such a fashion that they can be treated as such in some cases, but they
> > can't always be treated as such.
> 
> Here here.  You cannot expect to find UNIX semantics in a heterogeneous
> environment.
Here Here!
> 
> Now the humorous thing is that NFS goes to great lengths to virtualize
> the directory paradigm (as it clearly must), only to make the totally
> unsupportable and false assumption that the server is able to return a
> "cookie" that points to the "next" directory entry.
I can invision an OS without a marker to the next entry.  I would not
like to use one of these! ;-)

>  This happens to
> work in UNIX, where removing a directory entry results in simply
> marking the entry as free.  However, in some other systems, this is not
> the case.  A counter-example is VMS, where removing a directory entry
> changes the physical size of the directory, thus invalidating any
> outstanding "cookies" being held by clients.

WRONG!  The NFS directory structure fits into the VMS filesystem
quite nicely (provided you go under RMS).  The VMS directory is
a set of disk blocks (512bytes). That contain in alphabetical order
all the files in a directory by name and pointers to the headers
in the File header file at the root of the filesystem.  The QIO
call to read a directory takes the file id of the directory and
a "wcc".  This is a magic number which roughly translates into
an offset like pointer.  A wcc of zero is the start of the directory.
When a file is deleted the directory size may change but the wcc
for any individual entry will stay the same.  Most direcrtories after
quite a bit of use will have a bunch of unused numbers in the sequence of
wccs.  The wcc of a file will change if an entry is added.  Because
the files are in alphabetical order (UGH!), you may insert a file
AAB between AAA and AAC which have a wccs differing by only one.  In this
case AAB gets AAC's wcc and AAC is bumped up by one as is the next file's
until either the rest of the directory is incremented or a "hole" in
the numbering sequence is found.

This has potential for problems on a heavily modified directory but the
dirent cache routines on the client can be set so that this won't
be much of a problem.  Occasionally you might get a directory with
one file listed twice.
-- 
	David Robinson		elroy!david at csvax.caltech.edu     ARPA
				seismo-------!cit-vax!elroy!david UUCP
				ihnp4!cithep/
Disclaimer: No one listens to me anyway!