Return to BSD News archive
#! rnews 4980 bsd
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!inquo!in-news.erinet.com!imci5!pull-feed.internetmci.com!news.internetMCI.com!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: Sat, 20 Apr 1996 02:14:23 +0100
Lines: 106
Message-ID: <199604200114.CAA09041@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> <199604181734.SAA04797@kythera.demon.co.uk> <3176BCFC.154575ED@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:21940 comp.unix.bsd.freebsd.misc:17837
Terry Lambert <terry@lambert.org> wrote:
>Ray Auchterlounie wrote:
[...]
>] EAs are data streams on disk. Data with all sorts of interesting
>] effects maybe, but still data.
>You are (erroneously) assuming implementation.
I am yes. I wasn't intending to.
[ I knew I shouldn't have jumped into this thread :) ]
>Is the file ownership an attribute? Yes. Is it a "data stream
>on disk"? No. Does it work despite your objections? Yes.
Yes, in applications that understand it. For DOS applications running
in an emulator (for example) it would be useful if file attributes
could be (at least) read from a file.
[...]
>Much of what would constitute the space of "useful EA's" is a
>collection of *state information*, not a collection of data
>streams. State information that is sometimes the result of
>file system events and is *read only* to the user.
It could still be read as a file - "cat /proc/net/route".
I think /proc is useful - others probably dont.
[...]
>You are confusing exposed namespace and implementation. This
>is a fundamental error in your approach.
I wasn't intending to - in fact the opposite.
[...]
>You implement a loopback for name space exposure for these legacy
>backup applications. You discard the loopback when it is no
>longer necessary (when the legacy apps have been displaced).
This was exactly what I was trying to suggest in my first post in this
thread - obviously not very clearly. We are in fact agreed.
If you implement the FS "properly" but have the option of a
file-as-directory view/translation/loopback/whatever, then almost all
of the pro file-as-directory arguments go away.
Then of course when they realise that the native mode works so much
better, you wont have to argue with them anymore :)
[...]
>A very, vey simple version of this idea is the UMSDOS file
>--LINUX-.--- (why wasn't it -UMSDOS-.---???),
[...]
I suspect it was "LINUX" because at the time "LINUX" was easily
identifiable and "UMSDOS" wasn't - it is probably still less so.
It needs to be easily identifiable so people don't delete it when in
DOS mode... :)
[...]
>Oh well. Your choice to use NetWare in a mixed environment.
[...]
>If you change to a non-mixed environment of one kind or the
>other, you won't have these problems.
??? This was a "mixed" environment of PCs running DOS/Windoze and a
Fileserver (also PC) running Netware, how do we make it less mixed ?
Everything else was the other side of our router along with the rest
of the internet. The internet _is_ a mixed environment and is likely
to stay that way - considering the only current likely candidate for
homogenising it I'd like it to _stay_ mixed :)
[...snip backup problem details...]
>I don't see how this would lead you to buy a DAT drive, but
[...]
We could have had access to a DAT drive shared between research
groups (for a fraction of the cost), but this was on a unix box
elsewhere - so the tools that could talk to it (eg. tar) couldn't
backup attributes. So we bought our own... (with same problem).
[...]
>I think this name space exposure issue has been beaten to
>death: it is possible to provide it optionally to people
>who are willing to update kernel components and disk images,
>but insist on installing legacy tools. I don't think that
Until there are (working) replacements for all the legacy tools, people
have no choice. Even Micro$oft with all their marketing clout have
realised the need for backwards compatibility.
>is the case that should be optimized at the expense of
>design flexibility and robustness.
Agreed entirely.
Regards,
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)"