On Thu, Jul 09, 2009 at 08:56:54PM -0500, Peter da Silva wrote: > On 2009-07-09, at 06:41, Shot (Piotr Szotkowski) wrote: >> Surely you can?t do anything serious with a file based solely on its >> extension, and I guess you?d rather my UI would not have to look at >> the >> header just to choose an icon for a file, *and* the shell completion >> is >> so much easier to code if it only has to consider extensions ? but why >> wouldn?t a filesystem that, say, stores the file type in metadata, >> work >> better than extensions? > > Because using metadata for data, even something as simple as the UNIX > execute bit, is hateful. > > Metadata is a great place for storing information for managing access to > the file (permissions), caching information about the file (eg, > spotlight), and for tracking system level information (has it been > backed up, when was it created/modified/whatever). Metadata should not > be used for anything required to use the file (figure out the program to > open it, etcetera). Ideally, the file itself should contain that > information, but after 50 years of evolutionary negotiation the file > name and location has FINALLY reached the point where it can be reliably > used for that role across more than one OS (it took a LOT of work to get > things to this point. If you never had to deal with file names like > RL0:[1,54]TKB.SYS;1 or UNION*DEVEL.BUILD(JANE).CONF/REL be happy). > > It's been more than 25 years since Apple came up with their resource > forks, maybe 15 since BeFS, and a decade since NTFS file forks really > started getting attention, and there's no sign that there's going to be > any consistency in metadata in the next half century. Everyone is moving > AWAY from using metadata for anything that will break functionality if > it's lost. We do NOT want to go the other direction. Really.
Hooray for security labels. *retch*
