structure of desktop file directories

[Jerome Leclanche]

This seems like an implementation detail leaking into the spec. Why
should the lib assume the caches are out of date based on the
timestamp on applications/? System-wide changes are expected to run
u-m-d.

Anyway, I'm not against it; I think it's reasonable to move them to a
different directory. Though at that point I'd suggest moving it to
somewhere like /var/lib/shared-mime-info or something.
J. Leclanche


On Thu, Oct 3, 2013 at 5:05 PM, Ryan Lortie <desrt at desrt.ca> wrote:
> 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).
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg