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.
