Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: NFS on System V
Message-ID: <3742@umcp-cs.UUCP>
Date: Wed, 8-Oct-86 01:59:32 EDT
Article-I.D.: umcp-cs.3742
Posted: Wed Oct  8 01:59:32 1986
Date-Received: Wed, 8-Oct-86 20:12:47 EDT
References: <161@wang7.UUCP> <2438@phri.UUCP> <278@stracs.cs.strath.ac.uk>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Distribution: net
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 24

In article <278@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>The real trouble with NFS on non 4.[23] based systems are to do
>with the Berkeley additions that just slot into the NFS protocol
>- atomic rename, mkdir system call, symbolic links, long filenames
>and so on. It's curious how some of these additions make implementing
>NFS easier. I wonder which came first - the new 4.2 filesystem or
>the Network File System?

The 4.2 file system came first, but not without looking ahead.
NFS was perhaps the most pressing reason for the addition of mkdir()
and rmdir(), though there are many other very good reasons for
their existence.

Actually, NFS *broke* a number of the additions, in rather subtle
ways.  Atomic renames are hard to do with component-at-a-time path
resolution.  Sun claims that this is a `feature'; I think it was
a mistake.  (The proper way to do name resolution, if you ask me,
is to send the path components as counted strings, and have the
returned result include a file handle and a residual component
count.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu