Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!ukc!strath-cs!jim
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.unix.wizards
Subject: Re: Reading directories
Keywords: heterogeneity, NFS
Message-ID: <1243@stracs.cs.strath.ac.uk>
Date: 21 Oct 88 10:26:51 GMT
References: <30506@bbn.COM> <884@yabbie.rmit.oz> <331@talos.UUCP> <744@sequent.cs.qmc.ac.uk>
Reply-To: jim@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 51

In article <744@sequent.cs.qmc.ac.uk> liam@cs.qmc.ac.uk (William Roberts) writes:
>In article <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...........
>
>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. We have lots of grief because
>of programs which try to interpret directories via read(2), not
>noticing that they are actually coming from

The solution to that problem is to fix the broken programs, not to
kludge the NFS implementation by preventing programs from reading the
directory. In an ideal world, all the programs that need to know the
contents of a directory would use the "portable directory routines".

However, NFS should not prevent programs from reading remote directories
directly. There are some circumstances where this could be useful: to
see the underlying format of some NFS server's directory (assuming it
has one), or perhaps to look at empty directory slots to see what files
used to be there (assuming this is a reasonable thing to do).

NFS makes a big thing of representing heterogeneous files as random
access byte streams. Since UNIX implements directories as a "special"
type of file - but still a byte stream - they should be visible as byte
streams through NFS. If that breaks programs, tough. Preventing remote
directory reads will break these programs anyway. In any case, such
programs should have been fixed long ago considering how long have
readdir(), scandir() and friends been around.

I can see there are cases where remote directory reading is not
meaningful - from an NFS server that doesn't have directories for
instance. Dealing with cases like that for a generalised remote file
access protocol is going to be tricky. It is a kludge that NFS simply
imposes a blanket ban to avoid this hard and intractable problem. I
don't claim to know what NFS (or any other comparable protocol) should
do in these cases. I don't think it is reasonable to disallow the
remote directory as a byte-stream paradigm when the remote directory is
implemented in precisely that manner. NFS should allow this even if the
clients and servers have different byte sex and/or directory formats.
NFS has no business preventing user processes from doing something that,
IMHO, most people would consider reasonable.

		Jim
-- 
ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!uunet!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"