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.