GNOME Bugzilla – Bug 523028
add more rigorous thumbnail checks
Last modified: 2018-09-21 16:25:45 UTC
It would be nice to replace: gnome_thumbnail_factory_lookup gnome_thumbnail_factory_has_valid_failed_thumbnail gnome_thumbnail_factory_can_thumbnail gnome_thumbnail_factory_save_thumbnail gnome_thumbnail_factory_create_failed_thumbnail gnome_thumbnail_is_valid with versions that: [1] Replaced the "mtime" parameter with a GFileInfo parameter, to facilitate [2]. [2] Determined thumbnail freshness based on mtime, ctime, and file-size comparisons, instead of just mtime comparisons. The new ctime/file-size comparisons would only be made if the existing thumbnail had these parameters embedded as PNG text chunks, to stay compatible with http://people.freedesktop.org/~vuntz/thumbnail-spec-cache (or maybe we should regenerate these thumbnails, with the new data... not sure...) Tightening up the thumbnail freshness checks would eliminate these issues: a) Slow devices such as scanners or oscilloscopes on serial ports may write image files quite slowly. It can happen that a device writes an incomplete chunk at t = 10.1 seconds, and gnome creates a "failed" thumbnail associated with that filename+mtime. The device may then save the final bit of the file at t=10.4 seconds, but apps will still use the failed thumbnail. (gThumb avoids this problem by ignoring "failed" thumbnail if their mtime is less than 5 seconds old, bug 432759. I run into this issue when saving files from my RS-232-connected oscilloscope.) b) If a user enters a folder with incorrect permissions, "failed" thumbnails will be generated. If the user then chmods the correct permissions, new thumbnails are not currently generated because only the ctime changes, not the mtime. For example, see bug 516125. c) If you rapidly rename a batch of files with a shell script, you can end up with a new group of files that share some of the old file names and mtimes, but have different images. Obscure, but some users run into it - bug 522317. This is all fairly simple to do, code-wise. The main point of contention is whether it is worth doing. I feel it would be nice to plug these holes, because gnome does not offer a simple gui method of purging the thumbnail cache. Advanced users can use rm ~/.thumbnails, of course, but that is not elegant. - Mike
*** Bug 522317 has been marked as a duplicate of this bug. ***
Further note: mtime and ctime should be saved in two chunks each, one with seconds resolution, and one with nanosecond resolution. Not all filesystems support nanosecond resolution, but solaris and ext4 do. ext3 has one-second resolution. GFileInfo reports times with microsecond resolution, so we'd need to do some conversion. - Mike
Thumbnailing has been moved from deprecated libgnomeui to gnome-desktop. http://library.gnome.org/devel/gnome-desktop/stable/thumbnail.html
Michael, is this still a problem? Got a patch for it?
Well, the one-second resolution of the stored mtime is still a potential issue. The current gnome thumbnail functions rely on uri and mtime (in secs). I think it would be better if new functions were added, that passed a gfile instead. The functions could extract the uri, and mtime in microseconds from the gfileinfo. The mtime could be stored in the png chunks of the thumbnail, in the current second-resolution mtime chunk, and a new mtime-usec chunk. However... I'm not really in a position to pursue this any more, so close you can close the bug if you want... - Mike
Created attachment 356073 [details] [review] thumbnail: Switch to using GTimeSpan for mtime which has microseconds precision instead of time_t which has seconds precision. This is useful for when the file is modified for the final time less than a second after a failed attempt.
A patch for when we break ABI, or more the API to another library (gdk-pixbuf is looking good for that).
Use microsecond precision fixes a) and c). Not sure about b).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/17.