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!spool.mu.edu!howland.reston.ans.net!EU.net!Norway.EU.net!nntp.uio.no!nntp.uib.no!nntp-bergen.UNINETT.no!nntp-trd.UNINETT.no!newsfeed.sunet.se!news00.sunet.se!sunic!news99.sunet.se!news.uni-c.dk!ssv2.dina.kvl.dk!news
From: Per Abrahamsen <abraham@dina.kvl.dk>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: 11 Apr 1996 06:41:32 +0200
Organization: Royal Veterinary & Agricultural U., Copenhagen, Denmark
Lines: 70
Sender: abraham@babbage.dina.kvl.dk
Message-ID: <rju3yrv0cj.fsf@babbage.dina.kvl.dk>
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com>
<rjlok5zje0.fsf@babbage.dina.kvl.dk> <4kfmdm$dgs@coyote.Artisoft.COM>
NNTP-Posting-Host: babbage.dina.kvl.dk
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM<U{B+4e{k79.Ya{~':DblFPCg$
@60,BfLv2@SKZ19cMWK0/C'v;tM:|6B'R}U1rp6CL&kN({9<zF/V{:JCg27yC)9oZjeqcQawzKfiNL
t9}`vjmK["dRQC/qGFQq"%u|Q`:6{"Rz}b(dnl_"3$Jtqimi>|8MBp/
X-Newsreader: September Gnus v0.69/Emacs 19.30
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20948 comp.unix.bsd.freebsd.misc:16955
Per Abrahamsen <abraham@dina.kvl.dk> wrote:
] Now: The shell puts everything in the path with executable permission
] in the hash. If it is not really an executable, we get an error.
] This is rare, as you usually don't put non-executables in the path.
>>>>> "TL" == Terry Lambert <terry@lambert.org> writes:
TL> Here is the problem. You are changing this assumption, OR you
TL> are requiring the user to make the association each time they
TL> create an executable file, using a utility.
I have problems parsing that paragraph in a way that makes sense. I'm
describing a state that works fine now and will continue to work fine
with files-as-directories. Where is the problem? What assumption?
What association?
TL> The fix is IOTTMCO -- search out the a.outs.
What fix? To what problem?
TL> This is nearly
TL> a NOP if the FS uses a btree to store naming information,
Fine, then there is really no problem, right?
TL> but this whole "file-as-directory" argument is predicated
TL> on the assumption that we can never, ever, in the future,
TL> at any time, change the file system because we love our current
TL> file system and we can't bear to see it die so *much* that
TL> we are willing to kludge files-as-directories to avoid even a
TL> modest change to the FS.
You are being absurd here. There is no such assumption. Everyone is
in favour of a more efficient file system.
Files-as-directories isn't seen as a "kludge" we are willing to accept
as a way to avoid changing the file system, but as a clean extension
to an existing feature that avoids the introduction of a real kludge,
namely a special purpose mechanism for introducing file attributes.
TL> By harping on *one* example, which *could* be implemented
TL> as file-as-directory, though it would be a kludge and require
TL> changing the shells and the exec loaders, etc., you aren't
TL> really contributing anything to the idea of an "ideal filesystem".
s/file-as-directory/file-attributes/g and I agree with the paragraph.
TL> That's because it is rare for an a.out to become disassociated
TL> from its name, but with file-as-directory, you open a huge
TL> window allowing this to happen, and greatly complicate life in
TL> general.
You keep stating that, but you have provided no arguments for it.
TL> It *POSSIBLE* for this one application, but it is far from
TL> *DESIRABLE*.
You keep stating that, but you have provided no arguments for it.
TL> Clearly tcsh ignores the directory attribute.
Yet tcsh is one of the most popular shells for interactive use.
Maybe you should point out a *real* problem instead, to justify the
cost of introducing of an ad-hoc concept (file attributes) for a
problem that otherwise be solved by generalizing an existing concept
(directories).