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.