Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!decwrl!sun!guy
From: guy@sun.UUCP
Newsgroups: net.unix-wizards
Subject: Re: NFS on System V
Message-ID: <8424@sun.uucp>
Date: Thu, 23-Oct-86 04:43:28 EDT
Article-I.D.: sun.8424
Posted: Thu Oct 23 04:43:28 1986
Date-Received: Fri, 24-Oct-86 00:21:11 EDT
References: <161@wang7.UUCP> <2438@phri.UUCP> <278@stracs.cs.strath.ac.uk> <7961@sun.uucp> <292@stracs.cs.strath.ac.uk>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 55

> We can all see when the two products were first shipped, but which
> design was outlined first?

"outlined" in what sense?  Bill Joy was definitely "thinking ahead" when the
4.2 file system was designed, but since the 4.2BSD file system
implementation was complete before NFS implementation even started, the fact
that some idea that eventually ended up in NFS was first conceived before
some other idea that eventually ended up in the 4.2BSD file system was is
hardly interesting or relevant.

> [There must have been some element of "if I have this system call,
> it'll make that network file system operation easier to do".

Why?  Some element of "if I have this system call, it'll make some
unspecified network file system easier to implement because you won't have
to know how directories are put together on the other end" would have been
sufficient.  A grocery list of potential network file system operations is
hardly a "design" for a network file system.

> (Note, I'm distingishing a "network file system" from NFS.)]

Something you should have done in the original posting if you wanted to make
yourself clear.

> True, but I'd suggest that the initial design of both (whether consciously
> or not) went on in parallel. There are too many similarities for this to be
> just a happy coincidence.

Oh, good grief.  You have people designing a network file system whose first
implementation will be on a system with certain file system operations.  It
would be very surprising if the design of the network file system *didn't*
show some influence from the "native" file system.

Given that you have a "mkdir" system call, why should the implementors, say,
give each of the microoperations in a "make directory" operation on a UNIX
file system its own operation in the protocol, rather than putting in a
"create directory" operation - especially given that future implementations
of that network file system need not be on systems that have equivalents to
those particular microoperations?  Given that this network file system may
be implemented on non-UNIX systems in the future, why should it define
pathnames as being composed of 14-character-or-less file names?  Given that
the operating system that it is to be first implemented on supports symbolic
links, and given that there is no *requirement* that an NFS server implement
them (presumably you just get some error return back if you try to make a
symbolic link on a file system that doesn't support them), why should the
protocol not support symbolic links?

The similarities in question merely suggest that there was a flow of
influence in *one* direction; a bi-directional flow would be unnecessary,
and should not be assumed in the absence of evidence that cannot be
explained otherwise.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)