Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!asstdc.scgt.oz.au!metro!metro!news.nsw.CSIRO.AU!mel.dit.csiro.au!news.bhp.com.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!floyd.sw.oz.au!usenet From: jeremy@suede.sw.oz.au (Jeremy Fitzhardinge) Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Subject: Re: Ideal filesystem Date: 19 Mar 1996 05:32:40 GMT Organization: Softway Pty Ltd Lines: 93 Message-ID: <4ilgto$861@floyd.sw.oz.au> References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <4ia7im$i4m@usenet.srv.cis.pitt.edu> <4if9gb$4kh@park.uvsc.edu> NNTP-Posting-Host: suede.sw.oz.au X-Newsreader: knews 0.9.3 In-Reply-To: <4if9gb$4kh@park.uvsc.edu> To: Terry Lambert <terry@lambert.org> Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:19699 comp.unix.bsd.freebsd.misc:15712 In article <4if9gb$4kh@park.uvsc.edu>, Terry Lambert <terry@lambert.org> writes: >OS/2 EA's are not single-attachment, like Mac resource forks. You >can have an arbitrary number of them. It seems to me that EAs are a bad idea, in that they add a new abstraction to Unix which is not necessary and doesn't fit into the overall conceptual model very well. The real question is not "Do we need and should we add EAs?" The real question is "Why is there a difference between files and directories, and what would happen if we eliminated it?". I suspect the answer to the second question is "it could certainly be done, but it would confuse lots of things at least in the short term, and what's it good for again?". But with userfs, I've written filesystems where its quite possible to do things like: $ cd mailfs $ ls -F 1/ 2/ 3/ 4/ $ cat 1 From: jeremy@sw.oz.au To: jeremy@sw.oz.au Subject: Test A test $ ls -F 1 Date Received-By To _body/ From Subject X-Comment $ cd 1 $ cat _body A test $ cat From jeremy@sw.oz.au $ ls _body $ # Nope, no MIME parts $ cd .. $ rm 1 $ ls -F 2/ 3/ 4/ What's a file? What's a directory? >The 'non-silly feature' list includes: >1) Application icon information Feh. May as well build it into the executable. ELF is good for that kind of thing, if you're really excited by it. >2) Desktop position information for an icon Bad for any multiuser machine. >3) Character set attribution of files; you can use this You mean having multiple representations for the one file, or just the filename? Or just having encoding information associated with the file? >4) Compression headers for compressed storage on a[...] >6) Data migration information for migrating the file to/from[...] >8) ACL's (Access Control Lists), ala VMS, to allow finer[...] >9) NetWare style "trustee" information.[...] >11) "Installed image" priviledges, ala the SVR4 protections[...] You mean a general way for layers over the filesystem to store per-file metadata? >5) Name/location attribution so that they don't end up as > an inode number in lost and found: with full referential > integrity, fsck can put the files back where they belong. >10) Parent/predecessor/location information; ideally, you'd[...] Unix files don't have *a* name or location. And if you're writing a new filesystem, one hopes it will eliminate fsck altogether. >7) Creator application information, so that a document can > "know" the application needed to access it, and a desktop That's a pretty disgusting way of going about it. One doesn't need to know who created a file, but what the type of the file is. That works so far, but often a file is one of many types (a TeX source file is just plain ascii text; its something which TeX can format; its something which emacs knows how to handle specially). If you have unlimited filename lengths, encoding that kind of info into the filename is a useful shorthand, though it might be nice to have a MIME type associated with files. J