Re: Magic is useless!



On 06Jan2002 08:40PM (-0800), Seth Nickell wrote:
> 
> We can add support for this to GnomeVFS. We don't expose how the MIME
> type detection is done in the VFS api anyway, so it wouldn't be terribly
> difficult to use a metadata attribute when the file is stored on a
> ReiserFS filesystem. The reason that we also need magic sniffing is that
> we don't want the Macintosh dilemna where files get stripped of their
> properties if you move them to other systems. 

For similar reasons, we would need the ability to set the type for an
existing file, so that the type can be sniffed at download time or
whatever.

> Most major file formats already have a detectable magic byte
> signaturate, though some of the now prospering "human readable"
> formats using XML or whatever are a thorn in the side (particularly
> if they are compressed, grr). But this would be a good complement.

XML is reasonably OK, actually, since a proper XML document has a DTD
declaration at the top that you can look for. The main problem is
compressed files and archives, since you need to either look inside
the compression/archiving, or allow suffixes to take precedence for
those types (returning to the bad old suffix-based world for those
kinds of files). We really should come up with a solution to this in
gnome-vfs, since it is a frequent user complaint.

> Something that would be *really* nice to have, while I'm on the subject
> of filesystem metadata, is support for extended metadata (i.e. "user"
> defined metadata, where user == application programmer). It would be
> nice to tack information like the icon position or whatever directly
> into a file's metadata.

Indeed, if you have arbitrary keyed metadata like this, all you need
is a convention for an attribute name to use for the file type, you
don't need additional API for it. So I'd be more in favor of generic
key/value metadata at the kernel level. We can use that when
available, and fall back to our current XML file scheme otherwise.

  - Maciej

 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]