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