Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!PEGASUS.SCRC.Symbolics.COM!sned From: sned@PEGASUS.SCRC.Symbolics.COM (Steven L. Sneddon) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Message-ID: <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM> Date: Wed, 24-Dec-86 14:26:00 EST Article-I.D.: MEADOWLA.861224142645.6.SNED Posted: Wed Dec 24 14:26:00 1986 Date-Received: Wed, 24-Dec-86 21:51:52 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 55 Approved: tcp-ip@sri-nic.arpa [Everything in here is an opinion (mine to be precise). There may also be some facts here (I hope so, otherwise I'd better look for a different line of work). Is this better, mtr?] Date: Sat 20 Dec 86 10:58:38-PST From: David L. KashtanI am the person who did the VMS NFS implementation, so I think I am reasonably qualified to comment on NFS as it relates to non-homogeneous O/S environments: The VMS NFS implementation is a server-only NFS implementation. It uses the SUN User-Level UNIX NFS implementation and the 4.3BSD- based Eunice (in order to provide the necessary UNIX file-system semantics). Without Eunice this would have been a very major undertaking. I would most likely have had to re-implement a pretty good sized chunk of the Eunice file handling system in order to get NFS to work on VMS. So, in reality, the way to get an NFS up on VMS is to get VMS to pretend that it is UNIX. This is hardly something one would be happy about in a standard for non-homogeneous O/S environments. Agreed. [...] It is my feeling that the Lisp Machine NFILE (and its predecessor QFILE) remote file access protocols went much further in dealing with file access for MANY different types of operating systems and I am very disappointed that nobody even looked at them as examples when thinking about NFS. David ------- I have a problem with this sentence, even though I agree that QFILE and NFILE can support richer underlying filesystem models than NFS. My problem is that if one were to replace the part of NFS that does the File protocol with NFILE, you wouldn't get any better behaviour with regard to the need to implement UN*X pathname syntax on top of the foreign filesystem. Instead of NFS passing you a UN*X-style pathname string, you'd have NFILE passing you a UN*X-style pathname string, and you'd be no better off. As I see it, the problem is really the lack of support for anything but UN*X filesystem syntax in UN*X. Where the Lisp Machine systems differ is in their ability to accept a variety of pathname syntaxes, and to convert between them when necessary (such as when copying directory hierarchies), all the while sending a "string-for-host" in the syntax of the remote filesystem, rather than the syntax of the local filesystem. By the way, it's interesting that Lisp Machines, which were designed from the beginning to be used as workstations on a network, adopted the pathname syntax of host:string-for-host for 'open'. UN*X, which was designed as a self-contained system, has to indirectly chop a local pathname, in UN*X pathname syntax, into host and string-for-host via Special Files and Mount Tables. That the only thing you could pass to a UN*X 'open' is a UN*X pathname seems to me to be at the root of the problem. When I think about what it would take to change this, my head starts to hurt [I know my share about UN*X, too].