Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!news.cse.psu.edu!uwm.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!btnet!zetnet.co.uk!dispatch.news.demon.net!demon!mail2news.demon.co.uk!kythera.demon.co.uk
From: Ray Auchterlounie <rda@kythera.demon.co.uk>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: Thu, 18 Apr 1996 18:34:28 +0100
Lines: 124
Message-ID: <199604181734.SAA04797@kythera.demon.co.uk>
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4jpjb6$77c@park.uvsc.edu> <jlemonDpEw1v.4Ez@netcom.com> <4kfoqd$dgs@coyote.Artisoft.COM> <DpvCB7.xn@midway.uchicago.edu> <199604161704.SAA02116@kythera.demon.co.uk>
<31740EB4.20617DC8@lambert.org>
X-NNTP-Posting-Host: kythera.demon.co.uk
X-Newsreader: Brian's News Reader V0.9 [Linux]
X-Mail2News-Path: disperse.demon.co.uk!post.demon.co.uk!kythera.demon.co.uk
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21835 comp.unix.bsd.freebsd.misc:17742
Terry Lambert <terry@lambert.org> wrote:
>Ray Auchterlounie wrote:
[...]
>] If we separate the implementation from the interface using "views"
>] "translators" or whatever, then everyone can be happy. Implement EAs
>] however you want, (for whatever reasons) and provide a set of
>] interfaces to allow people to access them however they want.
>To be blunt: why do you want to manipulate EA's with existing
>tools?
To be even more blunt: Because its f***ing difficult to manipulate
them with tools that _don't_ exist !
>When you add an EA, you are adding something supranormal --
>something that you could not use an existing tool on in the
>first place.
EAs are data streams on disk. Data with all sorts of interesting
effects maybe, but still data.
We have a legion of existing tools to manipulate data streams in the
form of _files_. Map EAs to files and all these tools are available,
don't do it and all these tools are broken. Many of the programs that
would need fixing aren't yours or mine to fix.
>Exposing attributes in the FS namespace seems silly. To do so
>requires duplicating access control semantics for each EA to
[...]
Either EAs have separate access control or they dont (inheriting that
of the file) - if they do it needs storing, if they dont it doesn't.
>I agree with your division between imlementation and access
>issues, but I disagree that these are reconcilable differences.
Is that disagree that they _can_ be reconciled or that they _should_ ?
>To put this another way: I can't edit the default icon for
>an application now with existing tools, so I need not support
>that type of access for the association "default icon" in a
>new implementation.
What about the _data_ "default icon" (be it a filename, xpm data or
whatever). What happens to this _data_ when I backup my system using
tar/cpio/afio/proprietary-backup-program ?
Ok, so you need a new set of backup programs. That's only the
start. By the time joeuser has finished inventing uses for EAs you and
I never dreamed of, you need a new _everything_.
Examples, just from my experience with _existing_ systems:
1. ext2fs on Linux:
Has extended file attributes, secure deletion, append-only, etc.
Tools are provided of course, lsattr and chattr.
Backup ? - bye bye attributes.
Move file to another file system and back ? - bye bye attributes.
NFS mount ? - no access to attributes.
Supported in file-managers/browsers ? - not that I've seen
Result ? - little known or used
2. Netware (DOS clients):
Has file permissions, trustee lists, ownership etc., tools to access
and change these are provided of course. But existing tools can't.
Editors would let you open and edit a file you only had read access
to. Some would die (lose your work) when you then tried to
save. Fixing (even the ones I had source for) proved almost
impossible. I fixed Demacs (this was years ago) - the fix involved
shelling out to DOS and calling "rights" and parsing the output, for
every file opened. Now who's talking horrible kludges ? (and yes
please tell me a better way).
Existing backup tools couldn't save this information. No problem - we
got a (proprietary $$$) netware-aware backup tool. It managed to get
<10% of the data rate to tape that tar could - unusably slow, took a
lot of man hours to get (fudge) a fix.
Maybe our dat drive isn't right - lets try backup over the network to
shared dat on a unix box, no problem, just use tar. Hey, why did we
buy a dat at all ? Oh yeah, no attributes in tar backup, bollocks.
3. Now an example of how it perhaps should be done:
Modern macs can access dos floppies, want to take your work from a mac
home to your PC ? - no problem. Hey, what's this funny RESOURCE.FRK
directory and all the strange stuff in there. What use is copying the
mac resource fork if it's going to a PC ???
Take file home from mac to PC, view/edit the _file_, then go back to
the mac. Hey, neat, it remembers what type the file is...
I can think of more.
[...]
>] Ideal filesystem ?
>] ...one which is capable of being all things to all persons.
>Which is why I wanted to start with a flat (numeric) namespace
>with a variable granularity block store, then implement FS
>objects and events on top of that -- including the concept of
[...]
I _don't_ want to constrain your implementation. If some form of
translation isn't possible don't do it - but don't _not_ do it because
it's a kludge or seems ugly.
If your IdealFS _doesn't_ work with existing tools it may never get
used, if it doesn't get used people will be reluctant to modify
tools to work with it. If it works with existing tools but only
provides some features or is an ugly kludge, then people are much more
likely to use it, and demand native mode support.
ray
--
Ray Auchterlounie Research Student (still) at:
<rda@kythera.demon.co.uk> Signal Processing Group
<rda@eng.cam.ac.uk> Cambridge University Engineering Dept.
"Don't ask me about my thesis (TM)"