structure of desktop file directories

[Ryan Lortie]

hi list,

As many know, I've been doing work on a desktop file index that David
and I designed during the freedesktop Summit in Nuremberg earlier this
year.

The main purpose of this index is to reduce the number of IO operations
we need to do to get the list of all applications.  For this reason, in
order to avoid having to stat every file in the directory, we do the
usual trick of comparing the timestamp of the index to the timestamp of
the directory itself to find out if any apps have been installed/removed
since the last time the index was updated[1].

In order to avoid spurious updates to the timestamp on the desktop file
directories I want to move some files out of the toplevel directory into
a new subdirectory.

The non-application files that we variously store in the applications/
directory:

 - defaults.list
 - mimeinfo.cache
 - mimeapps.list
 - soon, the new desktop file index

I don't care too much about defaults.list because this is typically just
included as a static file by the operating system, so it doesn't change
much.

The mimeinfo cache and the desktop file index will be regenerated every
time a new application is installed.  Similarly, the mimeapps.list is
written to whenever the user changes their mime settings.  These writes
will modify the timestamp on the applications/ directory, causing us to
believe that the caches may be out of date.

Here's what I plan to do about this in GLib and desktop file utils:

 - when creating one of these files, create a .metadata/ directory

 - put the files in there instead

 - if not already done, symlink from the applications/ directory to the
 file inside of .metadata/ for backwards compatibility

 - for the new desktop file index, we don't bother with the symlink
 because there is no backcompat issue and we have a reason for wanting
 to read it directly from the .metadata/ directory (see [1]).

This means that we will only touch the timestamp of the toplevel
directory the first time we perform this process.  After that, future
updates will only end up modifying .metadata/, which means that the
desktop file index won't be "out of date".

Comments?




[1] note: we take care to note that directories like kde/ and kde4/ may
exist and use the same 'leaf' trick as find(1) does by inspecting the
linkcount on the toplevel directory to ensure that it has the expected
number of links.  we will expect one extra for the '.metadata' directory
which we will know exists if we were able to successfully open the
index.  if we determine that extra directories are present, then we have
no choice but to spider the directory until we find them (but we can
then apply the 'leaf' trick to those directories).