Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!news@seismo.CSS.GOV@sun.UUCP
From: news@seismo.CSS.GOV@sun.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Submission for mod-protocols-tcp-ip
Message-ID: <8612290832.AA11741@sun.Sun.COM>
Date: Mon, 29-Dec-86 03:32:06 EST
Article-I.D.: sun.8612290832.AA11741
Posted: Mon Dec 29 03:32:06 1986
Date-Received: Wed, 31-Dec-86 01:49:07 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: tcp-ip@sri-nic.arpa

Path: sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Need information on NFS
Summary: Pathname syntax/semantics and file formats are two separate issues.
Message-ID: <10851@sun.uucp>
Date: 29 Dec 86 08:32:06 GMT
References: <8612250637.AA05517@seismo.CSS.GOV> <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM>
Sender: news@sun.uucp
Lines: 15

> 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.

The problem with VMS pathnames has nothing whatsoever to do with the fact
that some operating systems keep file attributes like file format around and
that a certain level of those OSes (not the kernel, in the case of VMS, but
RMS) imposes a certain interpretation of the bytes in the file, based on
these file attributes, on its clients.  Those are separate issues; you can
build a system with a VMS-style pathname syntax but with no interpretation
of the file's contents below user-mode code, or a system with UNIX-style
pathnames but with VMS-style file attributes handled by something like RMS.