Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!news.gan.net.au!act.news.telstra.net!psgrain!usenet.eel.ufl.edu!usenet.cis.ufl.edu!caen!uwm.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!in2.uu.net!ausnews.austin.ibm.com!usenet From: zcorb@osdce.austin.ibm.com () Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Subject: Re: Ideal filesystem Date: 21 Mar 1996 17:36:33 GMT Organization: IBM Austin Lines: 57 Message-ID: <4is431$269g@ausnews.austin.ibm.com> References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <4ia7im$i4m@usenet.srv.cis.pitt.edu> <314A470D.CCE53F0@netcom.com> <4ijs72$cim@josie.abo.fi> <314E0DB7.624ACB10@netcom.com> <4irqph$n9d@josie.abo.fi> Reply-To: zcorb@emerald-tech.com NNTP-Posting-Host: osdce.austin.ibm.com X-Newsreader: knews 0.9.3 Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:19739 comp.unix.bsd.freebsd.misc:15752 In article <4irqph$n9d@josie.abo.fi>, mandtbac@news.abo.fi (Mats Andtbacka) writes: > >then HPFS surely must have limits on EA size and number? and probably >decently low limits, to avoid wasting ridiculous amounts of disk space >on inodes alone? (i've long wanted to find a good technical paper on >the structure of HPFS; does anybody happen to know of one?) >-- > "I'm more differed from than differing" -- Arthur Dent HPFS stores ea's in the inode, as long as they fit there. There is also a 4-byte "pointer" to a raw disk location where remaining ea information is kept. The HPFS design does not pose any limits on EA size or type. OS/2 imposes a 64K limit, basically because the file systems in OS/2 are still 16-bit and must deal with selectors and 16-bit offsets. I definitely fall on the side of wanting EAs implemented. Once you've seen them put to really good use, you realize how powerful they are. They are *not* analagous to Mac's resource forks. And they are useful for much more than icon data and type information. Just as a data point, EAs are also implemented in DFS. Here's an example of EA use: The EPM editor under OS/2 uses EA data to store font and color information about a text file. Then, if you're editing the file via EPM, you see the fonts and colors. If you're searching the file via grep, or diffing it, or paging it, or whatever you don't have binary font and color information mucking up your display. Another use: REXX on OS/2 compiles scripts to byte-code and stores the compiled script as an EA to the script file. Then, every time after the first time a script is run, it runs much faster. The Workplace Shell on OS/2 uses EAs to store icon and textual data about a file. Thus, any file can have a unique icon associated with it and that file's icon follows it around without having to keep some goofy database synced up, and without having to depend on a file extension and executable associations for an icon. Also, you can store comments and history information as EA data in the WPS. This is quite useful for, say, tracking changes to configuration files without having to keep a separate file synced up. Basically, if you ever think, "Gee. I'd like to save some information about this file without modifying this file's contents. I'd also like to have that information readily available from an easily accessed place. Also, I'd like the link between this file and the associated information to kept up automatically," then you've found a probable use for EAs. Sure, you can say, "Well, this or that can be accomplished without EAs. You just do xyz." However, you can also do multitasking under DOS. You don't need Linux. Of course, Linux makes it easier, much more robust, faster, etc. So do EAs with file information that's orthogonal to the file contents. -- Zac Corbiere zcorb@emerald-tech.com Emerald Technologies, Inc.