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 <de...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg