NFS on System V

[Chris Torek]

In article <278 at stracs.cs.strath.ac.uk> jim at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu