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!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!munnari.OZ.AU!news.ecn.uoknor.edu!qns3.qns.com!imci4!newsfeed.internetmci.com!howland.reston.ans.net!EU.net!sun4nl!rnzll3!sys3.pe1chl!rob
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Ideal filesystem
X-Newsreader: NN version 6.5.0 (NOV)
Reply-To: pe1chl@wab-tis.rabobank.nl
Organization: PE1CHL
Message-ID: <DpAGp3.3tD@pe1chl.ampr.org>
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> <31608939.342B2F46@netcom.com>
Date: Wed, 3 Apr 1996 13:41:26 GMT
Lines: 49
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20457 comp.unix.bsd.freebsd.misc:16439
In <31608939.342B2F46@netcom.com> Adam Megacz <kalessin@netcom.com> writes:
>> >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.
Who cares about the user's home directory?
Of course each file would have its own "directory" where these attributes
would be stored, and there is no problem with files having the same name
in another directory.
I.e. when there is an application /usr/bin/icon with an attribute
/usr/bin/icon/.icon, of course there can still be a /home/user/.icon,
why not??
>> >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.
The easiest solution for executable files is to (optionally) use a directory
for an executable program, as mentioned by others. It will be handled
by the existing tools without problem.
Rob
--
+------------------------------------+--------------------------------------+
| Rob Janssen rob@knoware.nl | BBS: +31-302870036 (2300-0730 local) |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+