Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!deller@seismo.CSS.GOV@vrdxhq.UUCP From: deller@seismo.CSS.GOV@vrdxhq.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8612250711.AA26780@vrdxhq.UUCP> Date: Thu, 25-Dec-86 02:11:06 EST Article-I.D.: vrdxhq.8612250711.AA26780 Posted: Thu Dec 25 02:11:06 1986 Date-Received: Thu, 25-Dec-86 18:43:16 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 69 Approved: tcp-ip@sri-nic.arpa Path: vrdxhq!deller From: deller@vrdxhq.UUCP (Steven Deller) Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Summary: BSD UNIX supports other filesystem names better than any other OS Message-ID: <2690@vrdxhq.UUCP> Date: 25 Dec 86 07:11:04 GMT References: <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM> Organization: Verdix Corporation, Chantilly, VA Lines: 58 In article <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM>, sned@PEGASUS.SCRC.Symbolics.COM (Steven L. Sneddon) writes: > . . . > you'd be no better off. As I see it, the problem is really the lack > of support for anything but UN*X filesystem syntax in UN*X. The UN*X filesystem syntax, at least BSD, with 256 arbitrary characters per file "level", and up to 4096 arbitrary characters total, appears to be a superset of any names needed by other OS's. We have, ourselves, provided a simple VMS pathname to UNIX pathname converter for keeping a VMS hierarchy on UNIX. It parses: ddnn:[dir1.dir2.dir3]file.ext;ver into ddnn/dir1/dir2/dir3/file.ext;ver There is special handling if ";ver" is missing (use one greater than the highest existing, or use ;1). The only problems we have, is when going from an arbitrary and "unlimited" naming scheme as BSD UNIX provides, to limited, heavily structured naming schemes in systems such as VMS. The solutions (for example, as found in Eunice or on Apollo machines) are not "pretty" because those file systems have so many restrictions on the characters allowed, and the meaning of those characters. I will admit to not having used SYSV, or other AT&T incantations of UNIX, so please do not confuse "generic UN*X" with the UNIX I know. The problem would be removed only if all systems used the same system. Having used about 100 systems in my 25 years of programming, I would strongly vote for BSD UNIX -- that is, no "operational" naming limitations for a normal user. > . . . > By the way, it's interesting that Lisp Machines, which were designed > from the beginning to be used as workstations on a network, adopted the > pathname syntax of host:string-for-host for 'open'. UN*X, which was > designed as a self-contained system, has to indirectly chop a local > pathname, in UN*X pathname syntax, into host and string-for-host via > Special Files and Mount Tables. That the only thing you could pass to > a UN*X 'open' is a UN*X pathname seems to me to be at the root of the > problem. When I think about what it would take to change this, my head > starts to hurt [I know my share about UN*X, too]. Sorry, but putting host names into file names at the application level is a step backward. I want to get to a file "/xxx/yyy/zzz" regardless of where it is located today. And I want the system administrator, or myself, to be able to relocate the file to where it makes the most sense, without breaking my application. Examined closely, the ONLY naming scheme that makes sense is a strictly independent pure hierarchy, with lots of name freedom. Now you can object to "/" as the separator of the hierarchical names, and you can object to the method for mapping logical names to physical addresses, but you really shouldn't object to an implementation of the only sensible naming approach. Steven Deller --::= | | | {verdix,seismo,umcp-cs}!vrdxhq!deller (Steven Deller) -- ::= | | | {verdix,seismo,umcp-cs}!vrdxhq!deller