This is a page with some ideas about improving the state of Metadata handling in GnomeVFS and Nautilus. It's a fairly random thought-dump at the moment. Please feel free to improve it.


The reasoning behind the existence of this page follows:

  • Many filesystems (ext3, ReiserFS, WebDAV, etc) support the storage of arbitrary name/value pairs for each file.
  • Currently GNOME ignores this data, to the point of destroying it while moving/copying files.
  • Using these metadata mechanisms, the owner of a file can set properties that are world visible.

reasons why this might be useful

Here are some nice use cases that this will help out with:

The user who owns a file could set a custom icon/emblems for that file on a WebDAV share and then anyone accessing that file from any computer would be able to see their icon and emblems.

We could use a 'mime_type' metadata value to store the mime-type of the file, eliminating the need both for filename extensions and for magic file type detection.

The "Notes" for a file (as accessible from the Nautilus properties menu) could be stored here.

As many other things as we can possibly think of should try to use this system.

multiple levels

In order to maintain the current level of usability (for example, users being able to set notes on other people's files) there needs to be two levels of metadata.

These two levels are called Global and Personal.

Global metadata is metadata that is stored with the file (using the facilities available on the filesystem). This type of metadata is therefore only useable by the owner of the file. This is really the only person who *should* be able to set globally visible metadata.

Personal metadata is analogous to the "set custom icon" feature; it only affects a single user. The custom metadata can be stored somewhere in files in ~/.gnome2/vfs-metadata/.

other filesystems

Naturally, all filesystems don't support the concept of storing arbitrary name/value pairs on a per-file basis. For these filesystems we can create a dotfile (.gnome-metadata for example) that contains a list of metadata for the folder itself and all of its contents (exclusive of subfolders).

This is probably OK since in 99% of situations (and really, all normal use cases), if a user owns a folder then they own all of the files inside of it (and vice versa). The decision to store metadata about a folder inside the folder itself (instead of inside the parent folder) deals with the case of a user wanting to set metadata on their home directory.

new API

In order for anything to happen there needs to be an infrastructure for dealing with metadata. This probably means a couple of new VFS methods. These methods would deal in raw name/values.

  • mime_type = gnome_vfs_uri_metadata_get( uri, "mime_type" );

The simple get call would return the personal value if it existed, otherwise it would return the global value. Failing that, NULL.

  • gnome_vfs_uri_metadata_set( uri, GNOME_VFS_METADATA_GLOBAL, "mime_type", "image/jpeg" );

A method to list all of the metadata associated with a file would also be nice (possibly return a GList or similar).

things to do with APIs

After the infrastructure is in place, the absolute first thing that should be done is to get the gnomevfs and Nautilus file operations to preserve metadata while moving and copying. Even the standard GNU coreutils (cp, mv, etc) do this these days.

After that goal is complete some nice tieins to gnomevfs and Nautilus could be added for the metadata. gnome-vfs could start reading mimetypes and Nautilus could start using it for notes, for example.

Other applications could also start using it. For example, when Gnumeric saves a document, it could set a metadata field of "mime_type" = "application/x-gnumeric". This would allow the user to reliably reopen Gnumeric documents without requiring a .gnumeric extension on them. (If you try to do this now, Nautilus will attempt to open the document using file-roller.)

Another nice example is when you download content from a website that doesn't have an extension (or has the wrong extension because it was generated by a CGI script). Epiphany should set the mime_type of this file to whatever was specified by the webserver.

Filename extensions really are not part of the name that the user has chosen for the file. The user should not have to deal with them. This is a rant for elsewhere, though.

After all of that, a nice UI could be added to allow the user to inspect and set their metadata values for a file. This probably is not a good candidate for inclusion in the already-crowded Nautilus properties for a normal user. It would be a nice integration option for more advanced users, though (possibly a separate app).

Attic/GnomeVfsMetadata (last edited 2013-11-26 20:32:35 by WilliamJonMcCann)