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. Kashtan 

    I 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].