Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!TOPAZ.RUTGERS.EDU!hedrick From: hedrick@TOPAZ.RUTGERS.EDU.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Message-ID: <8612191832.AA09278@topaz.rutgers.edu> Date: Fri, 19-Dec-86 13:32:03 EST Article-I.D.: topaz.8612191832.AA09278 Posted: Fri Dec 19 13:32:03 1986 Date-Received: Sat, 20-Dec-86 04:07:56 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 39 Approved: tcp-ip@sri-nic.arpa NFS has dealt with one set of machine dependencies: The RPC mechanism is well-defined, and works across machines. So you can presumably read directories and delete files. But once you want to get or put data, it assumes a Unix file model, in the sense that the file is assumed to be flat (no way to say get the Nth record, or retrieve based on a record key). Furthermore, no translation of data is defined. This shows up in the PC implementation. Unix uses LF as a line terminator. MS-DOS uses eitehr CR or CR-LF [I don't remember which]. So you can use your Unix directory to store you PC files, but if you then go to edit them from Unix, the line terminators will be odd. There is of course a utility to change formats. For many purposes PC-NFS is just fine. It lets you use Unix disks to augment your PC's disks, and the formats aren't different enough to cause real trouble. But you'd like to see a real machine-independent file system solve that problem. Unfortunately, it isn't clear to me how one would do it. That's presumably why by and large it isn't being done. You can't have the server just change line terminators, for several reasons: - binary files (e.g. executables) would likely get munged - you can't tell which files are text and which are binary - if you turn LF into CRLF, you change the number of bytes, and so random access by byte number isn't going to work I think NFS is useful across a reasonable set of operating systems. I'm glad Sun put the work they did into making it as machine-independent as they did. But I certainly don't think one could claim it to be perfect. By the way, several notes have talked about NFS "violating Unix semantics". The most common example is that file locking doesn't work across the network. It does now, in Sun release 3.2. I think it's unfair to compare the first release of NFS, which we used in production for 1.5 years across 2 different manufacturers' machines (Sun and Pyramid), with System V release 3's network file system, which still isn't very widely available. (The other major omission is that you can't use devices across the network. Just disk files. I'd certainly like to see that fixed, but I can't say that in practice it causes much of a problem. I'll be interested to see whether that is fixed in NFS by the time we have sVr3 in operation.)