On 7/16/07, Vegard Nossum <<a href="mailto:vegard@peltkore.net">vegard@peltkore.net</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > This problem occurs also when you want to send a file to someone else > or when you want to store a document with extended attributes on a > filesystem where extended attributes are not available. So what about > creating a special file that will serialize extended attributes. So the > data found in these attributes would not be lost. This is very possible. This automatically solves a lot of problems, also for instance that of losing metadata when you download a file over HTTP. (Just download both the file and its .metadata and nothing is lost; heck, Apache could be modified to serve these files virtually even if the file on the server has metadata stored using real fs xattrs).</blockquote><div> ... </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It would be nice to have a format specification for the serialized xattrs. However, this is not enough. There must also be a C library that implements the specification. If not, the file will never be used consistently. I think such a library should easily provide transparent access to native filesystem xattrs and serialized metadata file with as little user interaction as possible (ie. simple from user/developer point of view). </blockquote></div> There's also the question of what exactly gets stored in the xattr's.  Just the MIME type? This seems like a good time to jump in and make the suggestion I signed up to the freedesktop lists for - is there any interest in cloning Apple's UTI (Universal Type Identifier) metadata system?  It defines a heirarchical standard of file types, with rules on how each "legacy" type source (on Mac, that's file extension, MIME type and the old pre-OSX "creator codes") maps to a UTI id. It has several benefits over MIME types: - It's heirarchical, so any app that registers as being able to handle "plain text" also automatically gets registered to handle XML (and any dialect of XML), source code, etc.  (With MIME types or file extensions, you have to add specific rules to know that, for example, text/vxml is a subtype of text/xml - there are only 2 levels in the heirarchy.) - It uses reverse-DNS format for namespacing, whereas the only namespacing MIME types have is the "x-" prefix for non-standard types, which still leads to namespace conflicts if different organizations want to define similar but not identical types.  With UTI's we could define standard types as "org.freedesktop.SomeNewType", and if individual desktop projects or apps want to jump ahead and define their own without waiting for freedesktop consensus, they'd use "org.kde.*" or "org.gnome.*" - On Macs, there's the advantage that UTI info is stored in the filesystem using extended attributes, so there's always a UTI identifier associated with each file.  If it didn't originate on a Mac, the UTI can be inferred from file extension, MIME type if available, or whatever.  (I'm not sure if the Mac uses magic numbers or just ignores them, but if we clone them we'd certainly want to include libmagic as a source of "legacy" type info.) I'd recommend looking at the way the Mac stores its extended attributes on non-HFS+ volumes (I believe it uses a hidden ".DS_Info" directory).  If the format is simple enough, we might be able to clone it exactly, thus allowing Mac's to make use of our metadata  and vice versa automatically.  I also think that implementing an open-source UTI library would be a fun project that would provide a lot of benefits for any desktop that wants to use it.