Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: finding NFS dirs in csh? Message-ID: <10398@sun.uucp> Date: Fri, 12-Dec-86 14:47:16 EST Article-I.D.: sun.10398 Posted: Fri Dec 12 14:47:16 1986 Date-Received: Mon, 15-Dec-86 07:28:19 EST References: <772@gcc-milo.ARPA> <565@mcgill-vision.UUCP> Organization: Sun Microsystems, Inc. Lines: 48 Summary: Directories AREN'T files! > NFS breaks the directory-as-a-file paradigm 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. When you read a directory entry, you want the i-number (and any other numbers in the directory entry) 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. (Otherwise, it would *really* be non-transparent.) As such, you must use a system call that knows you're trying to read directory entries, so that they can be put into a standard form at the sending site and put into the native form at the receiving site. 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. In fact, if the two machines are, say, a Sun and a VAX, it would pretty much be *guaranteed* to get wrong answers! > 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. If "read" gets an I/O error, the standard I/O call doing the reading will return whatever its error/EOF indication is. The program can then use "ferror" or "feof" to distinguish between error and EOF. A program using standard I/O can do the same error checking that a program using "open()" and "read()" can. > 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! FYI, the way "find" does it is to "stat" the file in question and search through the mount table (see GETMNTENT(3), at least in the SunOS documentation), "stat"ing the "mnt_dir" field for each entry in the mount table and comparing its "st_dev" with the "st_dev" for the file in question. When they're equal, it's found the file system on which the file in question appears; the "mnt_type" entry contains the file system type for that file system. "nfs" indicates an NFS file system. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)