gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/01/88)
In article <7841@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >I hate to say this, AT&T: but "struct direNt" was a DUMB idea. >Incompatibility still reigns supreme. AAAAARGH!!!!! Excuse me for interjecting some facts here. When McKusick wrote the original 4BSD directory access routines, he called the new directory entry structure "struct direct", even though it was radically different from what all UNIX systems had called "struct direct" up to that time. When the same access interface started to be used for non-BSD UNIX systems (which in itself was a step forward), this incompatibility started getting seriously in the way. IEEE P1003 (NOT AT&T), in the process of standardizing the UNIX programming environment decided to fix this; the IEEE 1003.1 structure is called "struct dirent". AT&T based their routines supplied with SVR3 (which started out as my earlier public-domain implementation of the directory access library, which had followed Berkeley and used "struct direct") on the draft POSIX specification, thus "struct dirent". (AT&T also introduced a getdents() system call rather than reading the directory file directly; like the similar Sun system call getdirentries(), this helps with network file systems.) Later I also changed my public-domain implementation to match POSIX, AT&T, and the rest of the non-BSD world. (It is also much more generally portable than previous versions, and has the fastest seekdir() I know of.) I believe I heard Berkeley say they would also switch to "struct dirent", and that calling it "struct direct" in the first place had been a mistake.
rbj@icst-cmr.arpa (Root Boy Jim) (06/04/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa>
When McKusick wrote the original 4BSD directory access routines,
he called the new directory entry structure "struct direct",
even though it was radically different from what all UNIX systems
had called "struct direct" up to that time....
... I believe I heard Berkeley say they would
also switch to "struct dirent", and that calling it "struct
direct" in the first place had been a mistake.
Your recollection is correct. Here is his message:
From: Kirk McKusick <mckusick%okeeffe@berkeley.edu>
Newsgroups: comp.std.unix
Subject: Re: Changed names in POSIX directory access library
Sender: std-unix@uunet.UU.NET
Reply-To: mckusick%okeeffe@berkeley.edu (Kirk McKusick)
Date: 11 Aug 87 19:33:34 GMT
Apparently-To: std-unix-list
Cc: hoptoad!gnu@cgl.ucsf.edu (John Gilmore), gwyn@brl.arpa (Doug Gwyn),
utzoo!henry@sun.com (Henry Spencer),
longway!jsq@uunet.UU.NET (John S. Quarterman),
karels@okeeffe.berkeley.edu (Mike Karels)
From: mckusick%okeeffe@berkeley.edu (Kirk McKusick)
When I wrote the directory access routines I made a mistake in
connecting them with the underlying implementation of the file
system. They clearly should work on an abstract directory
definition which may coincidentally be the same as the underlying
directory structure (as it is in 4.3BSD). As such, I fully agree
with the decision in the POSIX standard to create a new header
file <dirent.h> rather than using <sys/dir.h>. It is the intention
of CSRG to change the source code at Berkeley to <dirent.h>.
I do take exception to the apparently gratuitous change of renaming
`d_ino' to `d_fileno' in the System V interface, though this can be
worked around with a #define.
Kirk McKusick
mckusick@berkeley.edu
ucbvax!mckusick
Volume-Number: Volume 12, Number 9
As for his disagreement about d_ino/d_fileno, I think the idea here was
to disassociate the idea of a (UNIX specific) inode from the idea of a
generalized file handle. And of course, defines work both ways.
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
My name is in /usr/dict/words. Is yours?decot@hpisod2.HP.COM (Dave Decot) (06/06/88)
> I do take exception to the apparently gratuitous change of renaming > `d_ino' to `d_fileno' in the System V interface, though this can be > worked around with a #define. > > Kirk McKusick > > As for his disagreement about d_ino/d_fileno, I think the idea here was > to disassociate the idea of a (UNIX specific) inode from the idea of a > generalized file handle. And of course, defines work both ways. > > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> It's irrelevant as far as POSIX is concerned: it now requires only the d_name field to be part of struct dirent. Dave Decot hpda!decot