Return to BSD News archive
#! rnews 4410 bsd Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc 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!news.ecn.uoknor.edu!news.cis.okstate.edu!newsfeed.ksu.ksu.edu!news.physics.uiowa.edu!news.drake.edu!newsrelay.iastate.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!in1.uu.net!mail2news.alias.net!myriad!mylinuxbox!suck!netcom.com!kalessin From: Adam Megacz <kalessin@netcom.com> Subject: Re: Ideal filesystem Content-Type: text/plain; charset=us-ascii Message-ID: <3176D25A.16701E2D@netcom.com> Sender: kalessin@netcom5.netcom.com Content-Transfer-Encoding: 7bit Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4jpjb6$77c@park.uvsc.edu> <jlemonDpEw1v.4Ez@netcom.com> <4kfoqd$dgs@coyote.Artisoft.COM> <DpvCB7.xn@midway.uchicago.edu> <199604161704.SAA02116@kythera.demon.co.uk> <31740EB4.20617DC8@lambert.org> <31745617.3E43CCA3@netcom.com> <3175A76B.363FDA96@lambert.org> Mime-Version: 1.0 Date: Thu, 18 Apr 1996 23:38:02 GMT X-Mailer: Mozilla 2.01 (X11; I; Linux 1.2.13 i486) Lines: 72 Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21990 comp.unix.bsd.freebsd.misc:17866 > ] > To be blunt: why do you want to manipulate EA's with existing > ] > tools? > ] > ] Some people really *love* Emacs. Why not let them use it with > ] EA's? Why make them rewrite emacs just so it can read EA's? > Emacs runs on the Mac and on OS/2... can it edit Mac resources > ot OS/2 extended attributes? If it can, we don't need to > rewrite Emacs... if it can't, then Emacs needs to be fixed, > since MacOS and OS/2 aren't going to change to suit it. Wouln't it be nice if Emacs and cat and tar and gzip worked on OS/2 EA's? But they don't. Since OS/2 is stupid in this regard, why does Linux have to be similarly stupid? Linux can offer backwards compatibility where OS/2 doesn't. > ] > When you add an EA, you are adding something supranormal -- > ] > something that you could not use an existing tool on in the > ] > first place. > ] > ] I disagree. > ] Consider "cat" (a clearly "existing tool") > > [ ... example of using 'cat' to dump attributes on an attribute > by attribute basis instead of using a "properties" command > like OS/2 and Windows 95 use ... ] > > Seems like gratuitous complexity to pound a bunch of round pegs > into a square hole because you love your square hole and are > afraid to pull out the drill and Do The Right Thing... Proof by analogy is fraud. I'm not doing any "pounding". Besides; what makes the Win95/OS2 way better? My way offers backwards compatibility. What does yours offer? My rule is "offer backwards compatibility whenever possible, except when doing so does impairs the quality of the final product." > ] > Exposing attributes in the FS namespace seems silly. > ] > To do so > ] > requires duplicating access control semantics for each EA to > ] > get it back to the level of control available to normal FS > ] > objects: owner, group, permissions, etc.. You end up needing > ] > nearly as much information as you do for a regular file. > ] > ] So? As was previously said, "inodes are cheap". Try > ] "df -i" If you're really obsessed with saving space, there > ] can be a filesystem-wide option declaring that EA's share > ] their parent file's permissions. However, I myself would not > ] advocate using this option except where disk space is at an > ] acute premium. > > "Inodes are cheap"?!? When did I say this? Terry, read my posting (above) carefully. I said "As was previously said". When did I ever mention YOU saying it? You're not the only one in this thread, you know. > ] > To put this another way: I can't edit the default icon for > ] > an application now with existing tools, so I need not support > ] > that type of access for the association "default icon" in a > ] > new implementation. > ] > ] How about > ] # XV /usr/bin/knews/.EAs/icon > ] So you *can* edit the default icon for an application now > ] with existing tools (XV). > > No I *can't* edit the *existing* default icon with the *existing* > tools, becuase there is *no such thing* as a file system association > of a file with an icon to attribute it as the default icon for an > application. Which is EXACTLY why we need Extended Attributes. :-) Couldn't have put it better myself.