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