Return to BSD News archive
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!asstdc.scgt.oz.au!metro!metro!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!gatech!newsfeed.internetmci.com!in1.uu.net!mail2news.alias.net!myriad!mylinuxbox!suck!netcom.com!kalessin
From: Adam Megacz <kalessin@netcom.com>
Subject: Re: Ideal filesystem
Content-Type: text/plain; charset=us-ascii
Message-ID: <31608939.342B2F46@netcom.com>
Sender: kalessin@netcom3.netcom.com
Content-Transfer-Encoding: 7bit
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
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> <4jnvb4$608@floyd.sw.oz.au>
Mime-Version: 1.0
Date: Tue, 2 Apr 1996 01:56:09 GMT
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i486)
Lines: 35
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20654 comp.unix.bsd.freebsd.misc:16624
> >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.
Fine. But how will you represent the icon for a directory? If you do it by using the syntax
"<filename>/.icon", then what would we do if such a file already exists? (i.e., say there is an
application called "icon" -- yes, one does exist -- that creates a file in the user's home directory
called ".icon"). Unless the kernel steps in to help, we get a major namespace problem.
> >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.
Actually, somebody found a soloution for this. We could store the object's content in
<object>/.content, and use some kind of hash-collision algorithm to avoid namespace problems. It's a
hack, but it works.
--
Adam Megacz <kalessin@netcom.com>
Website ftp://ftp.netcom.com/pub/ka/kalessin/adam.html
Linux - OS/2