From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Mon, 20 Aug 2007 08:47:53 +0000 From: jsnx Message-ID: <1187377796.983193.153800@j4g2000prf.googlegroups.com> Content-Type: text/plain; charset="us-ascii" References: <46C5638A.9080507@proweb.co.uk> Subject: [9fans] Re: everything is a directory Topicbox-Message-UUID: ac5de404-ead2-11e9-9d60-3106f5b1d025 On Aug 17, 5:06 am, quans...@quanstro.net (erik quanstrom) wrote: > > They already have synthetic file systems built into NT! > > i think it's worse thank that. attributes and their ilk essentially > add methods to a filesystem. That's overstatement -- attributes add 'user defined' types to the filesystem, but that's not the same thing as giving each filesystem object procedures. It might require polymorphic versions of ls, cat, &c. -- but probably not, since the extra fields aren't of interest to them. I've seen a lot of criticism of extended attributes on this thread, but no one has stepped up with a solution that addresses the problem they solve. Application specific data should go in the file -- we all agree about that. The file's position in the heirarchy is modeled by directories, which also carry OS specific metadata -- permissions, ownership. But where do the oddball intermediaries put their metadata? For example, where should the desktop environment put file specific icons or annotations? It can't very well stuff icons into your doom .wad files. In principle, the desktop could put that stuff in a mockup of the real file-system hierarchy, but having a /gnome/icons tree that had to be kept in synchrony with the 'real' filesystem invites a lot of semantic confusion, as well as an implementation hassle (broken links, new versions of 'mv', something else?). The fathers of Unix saw many things, but who's to say they saw all the metadata we will ever need?