Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!cit-vax!elroy!david From: david@elroy.UUCP (David Robinson) Newsgroups: comp.unix.questions Subject: Re: finding NFS dirs in csh? Message-ID: <2745@elroy.UUCP> Date: Wed, 17-Dec-86 07:18:03 EST Article-I.D.: elroy.2745 Posted: Wed Dec 17 07:18:03 1986 Date-Received: Thu, 18-Dec-86 01:37:39 EST References: <772@gcc-milo.ARPA> <565@mcgill-vision.UUCP> <10398@sun.uucp> <33@winchester.UUCP> Organization: Image Analysis Systems Grp, JPL Lines: 51 Summary: Not true on VMS In article <33@winchester.UUCP>, djl@winchester.UUCP (Dan Levin) writes: > In article <10398@sun.uucp>, guy@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@csvax.caltech.edu ARPA seismo-------!cit-vax!elroy!david UUCP ihnp4!cithep/ Disclaimer: No one listens to me anyway!