Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.bugs.4bsd
Subject: Re: 4.3 Tahoe rrestore bug
Keywords: 4.3,tahoe,restore
Message-ID: <506@auspex.UUCP>
Date: 25 Nov 88 19:02:17 GMT
References: <23669@pprg.unm.edu> <921@bacchus.dec.com> <486@auspex.UUCP> <936@bacchus.dec.com>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 29

>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).