🚀 go-pugleaf

To: John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.edu>
Cc: std-unix@sally.utexas.edu, utzoo.UUCP!henry@cgl.ucsf.edu
From: Doug Gwyn (VLD/VMB) <gwyn@brl.arpa>

I explained what the problem was with McKusick's implementation
and why both AT&T and IEEE 1003.1 decided to do it differently.
I also provided a public-domain package that can be built for
use on Berkeley-based systems, so the POSIX interface is
available there, too.  However, it is simply not practical for
most vendors to provide the Berkeley interface in a true System
V environment (more on this later).

You keep making noises that sound like you think there is a
conspiracy to reject correct Berkeley designs for various things
in favor of inferior approaches.  I've been at least peripherally
involved with almost all those situations, and that simply is not
what happens.  The real problem is that Berkeley keeps coming
out with stuff that has design or compatibility problems that
other people have to figure out how to fix later.  Such fixes
are not gratuitous changes to perfect designs!

You probably don't notice the problems because you work in a
Berkeley-based environment.  Try building some of your code on
real SVR2 systems some time and see what you break when you
change SVR2 to use the Berkeley <sys/dir.h> -- your code would
then work but there are a LOT of existing programs affected by
that incompatible change.  Real-world vendors have to accommodate
existing (pre-BFS/NFS) code that did the best it could under
prevailing circumstances while providing improved, portable
support for future applications.

I ran head-on into this directory issue when I ported UNIX
System V (user mode) onto 4.2BSD.  My solution was to throw out
<sys/dir.h> altogether, and provide (McKusick-compatible)
directory access functions for the System V environment.  The
reason I could do that was that I was in total charge of all
software to run in that environment.  When we started importing
code, the absence of <sys/dir.h> is the only thing that saved us
from wasting valuable time tracking down obscure bugs.  Vendors
that might have tried such an approach would have upset their
existing customer base.

My older package served as the basis for the one in SVR3, which
was modified by AT&T to conform to POSIX, which by then had
already identified the problem with using <sys/dir.h> and/or
(struct dirent) for the portable directory interface.  I fully
support the POSIX choice of names as a correct decision.

Until we get 4.4BSD (or whatever) into POSIX compliance, simply
build my PD package for BFS and use it with your portable code.

Volume-Number: Volume 12, Number 6