Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!gnu@lll-crg.ARPA@hoptoad.UUCP
From: gnu@lll-crg.ARPA@hoptoad.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: NFS could support general case pathnames pretty easily...
Message-ID: <8612270810.AA13941@hoptoad.uucp>
Date: Sat, 27-Dec-86 03:10:59 EST
Article-I.D.: hoptoad.8612270810.AA13941
Posted: Sat Dec 27 03:10:59 1986
Date-Received: Sat, 27-Dec-86 08:35:18 EST
References: <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 96
Approved: tcp-ip@sri-nic.arpa

There has been a migration from (mostly useful) criticism of Sun's NFS
to discussion and criticism of network file systems in general.  This is
OK, we should just not get confused about what we are refuting.

>     > As I see it, the problem is really the lack
>     > of support for anything but UN*X filesystem syntax in UN*X.  
> 
>     Since Unix filename syntax is a sequence of chars terminated
>     by a null (some systems have a maximum length, generally not
>     less than about 1024 bytes), its hard to see how this is much
>     of a problem.
> 
> Consider TOPS-20 directory structure, VM/CMS mini-disks, file system
> that permit "/" characters in their filenames, or especially file
> systems (like VMS and VM/CMS) that have structured (non-byte stream)
> files.  None of them map very quietly into a hierarchical set of
> directories separated by "/" characters, and there are more and harder
> where they came from.

Requiring Unix pathname syntax can be considered a fixable bug in NFS,
and (in an operating system with pretty flexible file names like Berkeley
Unix) need not be an issue in network file system access.

While I was at Sun, I suggested to the NFS group that the basic file
name lookup operations should be passed the entire file name and should
return "whatever part they had not handled".  This would allow the
system which actually implements the disk file structure to parse the
names involved.  For example, on Unix you could do:

	% cd /vm.cms
	% more 'humm zumm a'
	% cd /dg.aos
	% mail <:udd:toad:music:spheres tcp-ip@sri-nic.arpa
	% cd /rsx11m
	% grep meaning '[34,5678]mans.src;4'
or even
	% grep honestman '/vm.cms/whole world a' '/rsx11m/[1,2]buckle.shu'
and presumably if you wanted to spend a lot of time in e.g. a CMS file system,
you could write a "cms shell" that would parse your commands the way the CMS
interpreter does, rather than the way that's convenient for Unix.

However, this idea did not reach the NFS group until they were too far
along to consider it for the first release.  I still think it would be
a good idea, and it could be done by adding another remote procedure to
call with these semantics.  If an NFS client implementation tried this
call and it failed, it could remember that fact, never try it again in
that filesystem, and revert to the old way (parse up to the next "/"
character and call the old "look up name" procedure), providing
backward compatability.

There would still be a few loose ends, e.g. a leading slash (or some
other local convention on non-Unix systems) would still indicate global
rather than current-directory file naming, making it hard to get at
remote files in your current directory that begin with "/".  Also,
programs written for a particular operating system would make
assumptions about how to reach a parent directory, or what characters
are valid in file names, or how to turn "buggy.c" into "buggy.o" or
"hairy.txt" into "hairy.tqt" which would often prevent the use of
arbitrary remote files by those commands.  But no network file system
will solve that problem by itself.

>                                               mapping everything to UN*X
> syntax is a lot easier on UN*X applications than changing them all to
> handle a pathname representation designed to facilitate operations in a
> heterogeneous environment.  As it happens, the Symbolics environment
> represents pathnames and file system operations in a way that is
> optimized to heterogeneous environments.

I think Berkeley did a good enough job, especially given what they
started with and what System V still labors under.

If the filename parsing bugs in Sun's NFS are fixed, what will start
showing up are these application program bugs.  While Lisp is a nice
language, I don't think we should rewrite the world in it to solve our
pathname representation problems.  Better to define some standard hooks
and encourage their availability in a wide variety of environments,
e.g. dir_part(filename) would give the directory name;
file_part(filename) would give the filename within the directory;
parent_of_dir(dirname); file_in_dir(file, dir) would concatenate the
name of the dir and file; dir_in_dir(dir1, dir2) would concatenate two
directory names; root_dir() return the root of the naming scheme, if
any; etc.  I suspect that a set of 10 or 15 of these at most would be
enough to provide a 99% solution to writing applications that don't
embed file-naming-specific information, given an operating system that
supports hierarchy.

Some of these would be tricky, e.g. MSDOS does not implement a true
hierarchy, but has a separate root on each device (e.g. "a:foo" gets foo
in the current directory on disk a, while "a:/foo" gets foo in the root
directory on a, and "/foo" gets foo in the root on the current
disk).  My impression is that VMS is similar, though I've never worked
with it.

Of course, in a system that implemented NFS, these routines would have
to RPC to the remote system at run time to determine its conventions,
so they might not be cheap, but they would be correct.