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.