Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!rutgers!mit-eddie!husc6!necntc!encore!linus!philabs!micomvax!musocs!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.unix.questions Subject: Re: finding NFS dirs in csh? Message-ID: <586@mcgill-vision.UUCP> Date: Sun, 21-Dec-86 01:56:07 EST Article-I.D.: mcgill-v.586 Posted: Sun Dec 21 01:56:07 1986 Date-Received: Mon, 22-Dec-86 18:41:31 EST References: <772@gcc-milo.ARPA> <565@mcgill-vision.UUCP> <10398@sun.uucp> Organization: McGill University, Montreal Lines: 79 In article <10398@sun.uucp>, guy@sun.uucp (Guy Harris) quotes: >> NFS breaks the directory-as-a-file paradigm and writes: > DIRECTORIES AREN'T FILES!!!!!!!! They may happen to be implemented > on UNIX in such a fashion that they can be treated as such in some > cases, but they can't always be treated as such. Directories are, conceptually, not files. However, I know of no operating system on which a directory is *not* a file, albeit usually with an imposed format and special flags set in its inode analogue. > When you read a directory entry, you want [certain numbers] to be > presented in the format of the machine and operating system doing the > *reading*, *not* the format of the machine and operating system on > which they are stored. Sounds like a good reason not to mix big-endian and little-endian machines on a LAN. Sigh, if only the world could agree on a byte order....if everyone else went, I would even be willing to switch. > As such, you must use a system call that knows you're trying to read > directory entries, Read() certainly has that information available. It can look at the inode and say "hey, this call is reading from a directory!". Just because it hasn't had to historically doesn't mean it isn't allowed to. > so that they can be put into a standard form at the sending site and > put into the native form at the receiving site. EXACTLY. *Why* can't you just present a directory in what has always been the standard form - read() returning directory entries? You can ship it around the net however you like - I'm not fussing about NFS using a different rpc call to read directory entries, I'm talking about the user program level. Todd Brunhoff's RFS did this right; when read() is done on a directory it notices and byteswaps the i-numbers. What I would like to see NFS do is get the directory entries (how is immaterial) and then construct something that looks like what a local directory looks like. > If "read" worked on directories over NFS, any program that tried to > use "read" to read directory entries from a directory, rather than > "getdirentries" (SunOS) or "getdents" (System V, Release 3, and > probably some future SunOS release) would be quite likely to get > wrong answers. Only if read() weren't careful to check whether it's reading a directory. >> so an attempt to open() and read() a directory will produce errors. >> Since standard I/O insulates programs from these errors, > Standard I/O does no such thing. [...] The program can then use > "ferror" or "feof" to distinguish between error and EOF. Bad choice of words on my part. Lots of programs (eg, cat) simply do something like while ((c=getchar()) != EOF) assuming that EOF means eof (a very easy trap to fall into). >> a remote directory will look like an empty file to many programs. > Only to *broken* and *incorrect* programs, i.e. programs that assume > that any error/EOF indication from standard I/O is an EOF indication. > Such programs should be fixed! Easy to say. There are a lot of such programs. Even your SunOS (3.0) cat does this. If I cat an nfs directory it exits after printing zero bytes (no error message); it even exits with status 0. I'll be glad to fix it - but I need source. Not only do you not ship source by default, you want us to pay (and pay lots!) for it. And we're not even for-profit. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu