Linus Torvalds (torvalds@linux-foundation.org) on 1/28/09 wrote:
---------------------------
>slacker (s@lack.er) on 1/27/09 wrote:
>>Linus Torvalds (torvalds@linux-foundation.org) on 1/27/09 wrote:
>>>slacker (s@lack.er) on 1/27/09 wrote:
>>>>
>>>>What if you have 5 applications wanting to write metadata
>>>>about a file? Keep 5 textfiles around in a directory?
>>>
>>>No, keep their own damn databases, and index it by the
>>>filename or something. Different programs should just
>>>keep their data separate. They shouldn't mix it up with
>>>files that they don't control.
>>
>>1176 words, and you start with this. If the application is
>>indexing the files by name, what happens when the name
>>changes?
>
>You really don't understand the problems, do you?

I understand your complaint. I just don't find it to be a compelling argument in the context of actual computer usage.

I commented on the security issue, and the only conclusion I can draw from your continued focus on this topic is that you consider metadata to be dangerous, and it should never leave someone's computer without some warning popping-up which says, "please review metadata before sending." Metadata already exists within files, and people don't bother to wipe it clean before transfering files around. I merely recommend externalizing the metadata outside of the file's data stream, but strictly associated with the file at a low level (xattrs). This can only improve the security offered to the user, because it's possible to write a singular tool to wipe xattrs, but it's impossible to do the same for metadata embedded within all the different types of file headers.

This approach also helps avoid the problem of applications throwing-out structured metadata in file headers. Opening a JPEG in Adobe Lightroom might modify EXIF data created by Apple Aperture. The solution to this is to use namespaces. You could have namespaces in structured file headers, but this has the same problem which I'd like to avoid in the first place: metadata changing the file's data stream itself.

I don't follow your point about how a file rename "may well strip the data off the file." Why is it a "may?" Is this some boogeyman about how some tools may not acknowledge xattrs yet? Well then I guess the 10 tools that perform low-level file copies would need to be updated. Sure, this would lead to problems if you ran in to a file system which doesn't handle xattrs, but who cares? I already asked for a world which respects xattrs. Instead, you choose to live in a world of lowest-common denominators. You can argue that I'm being idealistic, and you're being a realist, but you're not. Do you use spaces in your file names? Do you use greater than 8.3 naming of files? Do you have files larger than 4 gigabytes in size? Of course you do. You just ignore the file systems which don't support what you want to do, probably in the name of progress or something else idealistic.

Lastly, I don't even have a problem with your directory-based approach, so long as (A) there's some structure to it, and (B) the operating system has an understanding of the structure. In fact, it's already been done; they're called "bundles," and they're used in NEXTstep and OS X. They're wonderful from a usability perspective, but they certainly aren't any better than xattrs when it comes to protecting the user from inadvertently sending metadata which they'd otherwise like to keep private, which is something I'd like to see you acknowledge.