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