Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!imci3!imci4!newsfeed.internetmci.com!news.kei.com!nntp.coast.net!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: 1 Apr 1996 07:07:16 GMT
Organization: Softway Pty Ltd
Lines: 62
Message-ID: <4jnvb4$608@floyd.sw.oz.au>
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> <4jc6q5$bgd@josie.abo.fi>
<315B0727.70172281@netcom.com>
NNTP-Posting-Host: suede.sw.oz.au
X-Newsreader: knews 0.9.6
In-Reply-To: <315B0727.70172281@netcom.com>
To: Adam Megacz <kalessin@netcom.com>
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20360 comp.unix.bsd.freebsd.misc:16359
In article <315B0727.70172281@netcom.com>,
Adam Megacz <kalessin@netcom.com> writes:
>> 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
>
>Yes... I've been thinking about this quite a bit. If we throw away the
>directory bit,
No, we don't.
>1. how would a user interface (bash, xfilemanager, etc) know if an
> object (general term for the file-directory complex) is a file or
> a directory? What would "ls -F" look like?
Just keep the distinction for convention's sake. If you mkdir, it
looks like a directory, if you creat it's a file.
>2. If an object has no files inside it (in it's directory), and it's
> data stream length is 0, is it a file or a directory?
Its always a file or directory. If it has no additional streams then
there's no need for a directory part (it would be created on demand,
I suppose).
>3. How do you specify EA's for a directory? In other words, how do you
> have an icon for a directory?
Tricky. I guess you could have some namespace magic; perhaps a magic
subdirectory which refers to the directories sub-streams
(dir/.EA for example). A little nasty.
>4. If we designate file types by <filename>/filetype, and
> "/usr/bin/groff/filetype" tells us "groff"'s filetype, then we
> can no longer have files with the name "filetype", since they would
> be interpreted to be indicating their parent object's file type.
> However, this could be solved by having all "attributes" start
> with a special character - like "$" or something else.
NO! "attribute" names are just a convention which usermode programs
use to store information. There's no kernel support; therefore, there's
no need to for the filesystem to enforce any form of name. If a program
expects to be able to do "open("file/type", O_RDONLY)", then you'd just
better be sure that you put a useful type under that name.
>5. This will basically kill tar, cpio, and other backup utilities, since
> they backup either a file's contents, or the subfiles, but never
> both.
Yes. They'd need to know how to recurse into a file-complex. Representing
it would be easy enough (it would just appear as a regular file with
subdirectories), but you'd need to modify them to work propery.
>6. How do we "emulate" the directory bit for existing apps?
No need. Just make it a real part of the file's mode bits.