Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!husc6!rutgers!mcnc!rti!talos!kjones From: kjones@talos.UUCP (Kyle Jones) Newsgroups: comp.unix.wizards Subject: Re: Reading directories Message-ID: <343@talos.UUCP> Date: 24 Oct 88 14:37:30 GMT Article-I.D.: talos.343 References: <30506@bbn.COM> <884@yabbie.rmit.oz> <331@talos.UUCP> <744@sequent.cs.qmc.ac.uk> Reply-To: kjones@argus.UUCP (Kyle Jones) Organization: Philip Morris Research Center Lines: 27 In <331@talos.UUCP> kjones@talos.UUCP (Kyle Jones) writes: >It is clear why directories should not be arbitrarily writable but I >don't see any such reason why they shouldn't be readable. The portable >directory reading routines could use the existing read(2) system call, >instead of adding (yet another) system call just to read directories. In <744@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes: >This is too narrow a view in the world of networks and >distributed systems - the "portable directory routines" exist >so that the code *above* them is portable, not so that the >routines themselves are portable. I didn't say that the portable directory reading routines needed to be portable. I questioned the need for these ruotines to have to use another UNIX system call *just* to read directories when UNIX file semantics make it possible to use an existing system call. (And behold, what does getdirentries(2) do but fill a buffer, just as read(2) does?) If I can use read(2) to get input from something as idiosyncratic as a teletype, why can't I (or the portable directory reading routines) use it to read directories? Wouldn't it have been just a simple to make read(2) (when reading a directory) fill the buffer pointed to by its second argument with the same information that the getdirentries(2) call provides? kyle jones