Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news00.sunet.se!sunic!news99.sunet.se!news.funet.fi!news.abo.fi!not-for-mail From: mandtbac@news.abo.fi (Mats Andtbacka) Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Subject: Re: Ideal filesystem Followup-To: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Date: 27 Mar 1996 20:01:09 GMT Organization: Unorganized Usenet Postings UnInc. Lines: 31 Distribution: comp Message-ID: <4jc6q5$bgd@josie.abo.fi> References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <4ilgto$861@floyd.sw.oz.au> <4j6if4$15gk@news.missouri.edu> <315834CD.7C4DA6C7@netcom.com> Reply-To: mandtbac@abo.fi NNTP-Posting-Host: aton.abo.fi X-Newsreader: TIN [UNIX 1.3 950520BETA PL0] Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20341 comp.unix.bsd.freebsd.misc:16340 Adam Megacz, in <315834CD.7C4DA6C7@netcom.com>: >The reason I bring this all up is because you really can't go >"inbetween" #2 and #3; you have to go one way or the other. I myself >am unsure of which method I support; each has advantages (#2 is more >in harmony with "The UNIX way", i disagree. your second alternative (clear distinction between EA's and files) adds definite confusion to the existing concept (where a file is _only_ a byte stream, and _all_ structure is in the filesystem), whereas your third alternative - no distinction between a file/ea and a directory - is "cleaner", looks less like something with something else bolted on the side, and since it bears some fleeting resemblance to the existing files-are-data-directories-give-structure paradigm, could be said to be closer to "the Unix way". if you're going to do this, go all the way and go with #3. if a file is no longer a simple byte stream, then there is no reason why it should have only one set of permissions (or ownerships!), nor any reason why its subparts (EAs) shouldn't be able to have subparts of their own. anything less would be introducing arbitrary and silly limitations that are bound to break sooner or later. the more general solution - like somebody posted a userfs example of - is better, in my eyes anyway. for the record, i'm happy enough with the existing idea that i likely wouldn't change in any hurry (even though i can see some reasons why i'd want to - adding a content-type to text files is a Good Thing for us in ISOLatin-1-land!), but if i'll ever use any system like this it won't be any half-assed, half-useless compromise. all or nothing. -- "I'm more differed from than differing" -- Arthur Dent