Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!newsfeed.internetmci.com!news.mathworks.com!zombie.ncsc.mil!news.missouri.edu!vortex.cc.missouri.edu!rhys From: rhys@vortex.cc.missouri.edu (Justin "Rhys Thuryn" McNutt) Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Subject: Re: Ideal filesystem Followup-To: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Date: 25 Mar 1996 16:43:16 GMT Organization: University of Missouri - Columbia Lines: 157 Message-ID: <4j6if4$15gk@news.missouri.edu> References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <4ilgto$861@floyd.sw.oz.au> NNTP-Posting-Host: vortex.cc.missouri.edu X-Newsreader: TIN [version 1.2 PL2] Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:19947 comp.unix.bsd.freebsd.misc:15943 Jeremy Fitzhardinge (jeremy@suede.sw.oz.au) wrote: : 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. Question everything. Does the model itself need changing? Computers are supposed to *aid* us, not *hinder* us. If EAs will help people *use* computers, then they are a good thing, and it is up to the programmers to find a Good Way(tm) to implement them. Abstractions about files already exist. Is it a file or a directory? Is it an application or a data file? Is it a file (hard link) or a symbolic link? Is it a device file? Is the device a block or character device? Is it a socket? Unix sees everything as a file, but *users* don't. EAs, whatever they *do*, should be part of the inode, so that the OS can still see everything as a file, but users can take advantage of whatever the EAs offer. If the inode size has to increase to two blocks, so be it. : >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. I agree. The icons themselves should be built into the executable. This is probably one of the *very* *very* few things that Windows 3.0 did right. The icon is *in* the binary. Simple. Useful. Effective. : >2) Desktop position information for an icon : Bad for any multiuser machine. And way too complicated to store in an inode, and useless. The location of a file in the filesystem *means* something. Where an icon sits on the desktop is almost completely irrelevant. Leave icon placement to the window manager (or file browser). : >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? I think he is trying to solve the following problem: I am using a French ANSI character set. When you, the Brit, read my file, a lot of it comes out as unreadable characters. He wants to solve that problem by putting the character set information in the inode. It's not a bad idea, but it could get confusing. What about devices? What about directories? Some more discussion on this would be helpful. : >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? 8, 9, and 11 above sound like a good idea, particularly number 11. SUID/SGID is still a good idea, but in many cases, like the sendmail example earlier, it is too powerful. Anything that allows me to get closer to "minimum necessary access", especially in automated apps and daemons, gets my support. As far as 4 goes, I like things the way they are now. Gzip is a great program. If we start making the OS compress everything (disks, memory, etc...) we're going to see these wonderful new processors run like 386s. In other words, I think that making any part of the OS deal with compression is adding an unnecessary layer of overhead. I want my files messed with by *me* and *me* *only*. : >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. One would hope so, but anyway, here's his point (I think) again: If an inode contained the information about its location inside itself, you could do away with lost+found altogether. If the directory structure got screwed up, fsck (or whatever is "in charge" of the filesystem) could just do a MacOS style "Rebuilding the desktop (read: filesystem)" and go through the location information in the inodes to reconstruct the directory structure (if a directory "file" got trashed, the inode would contain its location and permissions, and the "contents" would be recreated from other inodes). I am unclear about this next part, so I am going to state how I *assume* it works, and then suggest how this would fit into the above: A hard link is just another inode pointing to the same data as another inode. DOS would throw a fit, calling this "cross-linked files". Unix doesn't care. Anyway, each hard link would contain location information for itself, not the file contents. A symbolic link would be the same way. The "contents" of the link are just a pointer to the "real" file. The location information would contain the location of the link. For example the link in /lib "libm.so" would *contain*: "libm.so.5". However, it's *location* information in the inode would be "/lib", since the *link* is in /lib and points to libm.so.5. So you'd only get messed up dir structures if *inodes* got screwed up, in which case you have bigger problems than just a trashed FS. Your files themselves are probably nuked to, and you disk is probably making funny noises. :) : >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. This is where I differ from many people. I don't *like* the OS, or anything else, assuming what's in a file based on the filename, inode information, or anything else (exception: difference between a file and a directory). When I tell grav to open a file, I want it to open that file! If it isn't a graphic, I want it to complain, but I want it to *try* first. Perhaps if when I "execute" a data file the OS or the shell or whatever brought up a customizable list of apps that I can choose from that are in some way related to the file, it would be nice, BUT: a) This shouldn't be a part of the filesystem. The programs associated with files will differ from system to system. Filesystems shouldn't have to know anything about the contents of your machine. In other words, the filesystem shouldn't have to know whether or not you have one or another app installed. It should only have to know hard information about the file, not abstractions like: "what is this file used for?". b) I can't tell you how much I *hate* the way the Macs implement this. Once a file has been "associated" with a particular app, it's a pain in the rear to change the "creator" application (once a Word doc, always a Word doc). See a) above. -- "My doctor told me to stop having intimate dinners for four, unless there are three other people." --Orson Welles rhys@vortex.cc.missouri.edu