Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!std-unix From: gwyn@brl.arpa (VLD/VMB) Newsgroups: comp.std.unix Subject: Re: Changed names in POSIX directory access library Message-ID: <843@uunet.UU.NET> Date: Sat, 8-Aug-87 10:52:48 EDT Article-I.D.: uunet.843 Posted: Sat Aug 8 10:52:48 1987 Date-Received: Wed, 12-Aug-87 01:45:22 EDT Sender: std-unix@uunet.UU.NET Reply-To: Doug Gwyn (VLD/VMB) Lines: 52 Approved: jsq@uunet (Moderator, John Quarterman) To: John Gilmore Cc: std-unix@sally.utexas.edu, utzoo.UUCP!henry@cgl.ucsf.edu From: Doug Gwyn (VLD/VMB) 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 -- 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 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 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 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