Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.bugs.4bsd
Subject: Re: 4.3 Tahoe rrestore bug
Message-ID: <8979@smoke.BRL.MIL>
Date: 26 Nov 88 01:49:48 GMT
References: <23669@pprg.unm.edu> <921@bacchus.dec.com> <486@auspex.UUCP> <936@bacchus.dec.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <936@bacchus.dec.com> vixie@decwrl.dec.com (Paul Vixie) writes:
>In article <486@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
># 	1) The directory library routines use "getdirentries()" in 2.x
># 	   and 3.x releases, and "getdents()" in 4.0.
>One question, if you (or anyone else) knows: why was this change made?  I
>know Sun would never, ever make a gratuitous, incompatible change to the
>semantics of a library routine.  What was the motive (this time)?

getdirentries() and getdents() are two system call interfaces that perform
essentially the same function.  One was invented by one organization and
the other by another company.  getdents() is the UNIX SVR3 flavor.

My public-domain implementation of the directory routines isolates all the
UNIX system vagaries in a (possibly emulated) getdents() function; when
getdirentries() is available, the getdents() emulation uses it.  On
systems without sufficient kernel support, the getdents() emulation reads
the directory file directly (two flavors of that: one for the original
UNIX file system and one for the 4.2BSD long-entry-name file system).
The direct-reading scheme would not work right for so-called "transparent"
network file systems unless the network file system maps the directory
entries to the local format.  Most don't do this but some do.