4.3 Tahoe rrestore bug

Guy Harris guy at auspex.UUCP
Sat Nov 26 05:02:17 AEST 1988


>One question, if you (or anyone else) knows: why was this change made?

Which change?  The change to use "getdirentries()" or the change to use
"getdents()"?

The former change was made so that directory reads could be
distinguished from plain reads of a directory file.  Directory reads
should return information in some standard format, regardless of how the
actual directory file is represented. 

An alternative would have been to make the "read" system call, when
executed on a directory, act like "getdirentries()" or "getdents()";
this would actually have broken more existing binaries than adding
"getdirentries()" (at least with a new system call, old binaries could
continue to read UFS directories, although they might fall apart on
directories read over NFS, or directories read from a V7/S5 file system,
or...).  You have to return a "directory cookie" with each directory
entry, so that the system can give you the "directory cookie" when you
do a "telldir"; you can't assume that the underlying directory works
like a UFS directory (i.e., that you can calculate how much some
internal seek pointer has moved, based purely on the data you got back
from the "read"). 

The latter change was made because "getdents()" has a better interface
than "getdirentries()"; instead of returning one directory "cookie" that
gives an "address" within the directory, it returns one for each entry,
so that the software doesn't have to assume it "knows" how directory
cookies work.  The NFS "readdir" operation resembles "getdents()" more
than it resembles "getdirentries()" (for that reason). 



More information about the Comp.bugs.4bsd.ucb-fixes mailing list