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).