*BSD News Article 64448


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!asstdc.scgt.oz.au!metro!metro!munnari.OZ.AU!news.unimelb.EDU.AU!news.rmit.EDU.AU!harbinger.cc.monash.edu.au!news.cs.su.oz.au!floyd.sw.oz.au!usenet
From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: 28 Mar 1996 07:22:02 GMT
Organization: Softway Pty Ltd
Lines: 52
Message-ID: <4jdemq$1l7@floyd.sw.oz.au>
References: <4gejrb$ogj@floyd.sw.oz.au> <3140C968.20699696@netcom.com>
  <4ilgto$861@floyd.sw.oz.au> <4j6if4$15gk@news.missouri.edu>
  <315834CD.7C4DA6C7@netcom.com>
NNTP-Posting-Host: suede.sw.oz.au
X-Newsreader: knews 0.9.6
In-Reply-To: <315834CD.7C4DA6C7@netcom.com>
To: Adam Megacz <kalessin@netcom.com>
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20159 comp.unix.bsd.freebsd.misc:16154

In article <315834CD.7C4DA6C7@netcom.com>,
	Adam Megacz <kalessin@netcom.com> writes:
>#2 supporters would advocate that the EA's share the same permissions as their parent
>files, and that a different syntax be used to access the EA's on a file. For example,
>    more /usr/bin/groff::filetype
>or something other than "::". The advantage of this is that one can tell whether a
>given pathname refers to a file (absence of ::) or an EA (presence of ::).

This kind of thing gets messy really quickly.  Some examples:

I want to find all the gif files here; compare
	grep application/gif */type
to
	grep application/gif *::type

The latter won't work, because all tools which glob don't know about this special
"::" syntax.

What if I want to find all the EAs on a file: "ls file::" looks very
odd to the eyes of a Unix person; "ls file/." is more sensible.
(And the former example just doesn't work if I want to use globbing:
"ls file::help.*")

I have some help text associated with a config file.  The help text is
encoded in some way, so my browser needs to know its encoding.  Will
this work "cat config::help::encoding"?  Why not "cat config/help/encoding"?

The point is that adding new pathname syntax like "::" (or anything else which
isn't a '/') just breaks things and introduces logical inconsistencies into
the way a filesystem namespace is constructed, particularly since all reasonable
definitions of "::" make it the same as "/".

Therefore I'd say that

>(#2 is more in harmony with "The UNIX way", though it could, in
>some cases, break legacy apps)

is *not* the case, and in fact the opposite is true.  And if you're calling
"ls", "cat" and "/bin/sh" legacy apps, what do you think Unix is anyway?

Furthermore, I don't see why its necessary that "EAs" have the same
permissions as the main file.  It would certainly be a useful default
(look at what the sgid bit does on directories), and commands like
"chmod" could maintain that, but I can think of numerous applications
where the "EAs" could usefully have different permissions or even
owners (particularly if the "EA" is not a file, but a link).

As I see it, a file is a file is a file;  all we're talking about is a
new way of naming them.

	J