GNOME Bugzilla – Bug 150483
No UI for deleting thumbnails, which never go away on their own
Last modified: 2008-04-11 12:48:32 UTC
When a thumbnailed file is deleted in nautilus, the corresponding file in ~/.thumbnails is not deleted. This leads to an accumulation of redundant thumbs, which waste disk space.
Created attachment 30719 [details] [review] Patch to add "Clean up thumbnail cache" and "Empty thumbnail cache" buttons to prefs dialog The attached patch against CVS adds functionality to nautilus-file-management-properties: "Clean Up Thumbnail Cache" - Delete all those thumbnails which do not point to existing files. "Empty Thumbnail Cache" - Delete all thumbnails The UI is basic: the dialog is made insensitive while the process is carried out, which can take up to about 10 seconds for about 50 megs of thumbs on my athlon 1800. It would be nice to have the "Clean Up" run automatically on login/logout or something, but it's probably too slow (has to open all thumbs to get PNG metadata). What would be really nice would be to have nautilus never leave the crap lying around to begin with, but that's beyond my abilities. Same patch, but against 2.6.3 is at http://icculus.org/~jcspray/nautilus_thumb_20040818.patch
Created attachment 36043 [details] [review] Updated patch, implementing progress dialog for thumbnail cleanup process This adds a HIG-compliant progress dialog for the thumbnail cleanup process, as well as a bit of a cleanup of the code in general. Can I get some feedback please?
Created attachment 36044 [details] Screenshot of thumbnail cleanup UI This is what happens when the user clicks "Clean up thumbnail cache". There's no progress dialog for emptying thumbnail cache, because it's so fast. One potential enhancement (at the expense of further clutter in the prefs dialog) would be to move the cache cleanup/empty buttons to their own header on the same tab, with a label telling how much space is currently being taken up by thumbnails.
Will there be a patch for nautilus 2.10.0? Noticed that my thumbnails directory is quite large so it would be nice to have this feature in nautilus.
I was using that patch with GNOME CVS right up until the 2.10 release, so yes, it does. At least, it didn't conflict with the CVS updates: whether it still applies cleanly I don't know.
Why not delete the files at move/delete time? On most file systems deletes are quite fast, surely the extra seek to .thumbnail is not a problem.
Another option would be to delete thumbnails which haven't been accessed for a long time periodically.
This bug is related to bug 141073 There I suggested to remove the .thumbnail/failed directory from time to time, because if your system get upgraded it might be that the thumbnail can get generated. So instead of just going recursively through the directories it might be a good idea to just scan certain directories in the .thumbnail dir
> "Clean Up Thumbnail Cache" - Delete all those thumbnails which do not point to existing files. Does it take extra care not to remove thumbnails for files on CD-ROM or other removable devices? Those thumbnails does not always point to existing files and recreating them on a slow medium is a bit annoying.
Sven: Well so you think for the 5 dozens of medias a user may have the thumbnails should be kept around just because they are slow to generate? Quiet counterproductive IMHO... .
Ubuntu bug about that: https://launchpad.net/products/nautilus/+bug/37643
*** Bug 100653 has been marked as a duplicate of this bug. ***
The solution presented seems to be solving the wrong problem. Users don't want to delete or clear their thumbnails. They just want the cached images to be correct. The right way to solve this is to have Nautilus be less naive about expiring thumbnails. It's not sufficient to check if the mtime is exactly the same, you also want to check if access(..., R_OK) says the same thing, and if the file size is exactly the same. Only if those three conditions are true should you use the thumbnail cache.
Simon: it's not just about getting rid of invalid thumbnails. Even just the valid thumbnails can take up quite a lot of space, which the user might want to reclaim. After all, the user was never asked by nautilus "May I have several hundered megabytes of disk space to store thumbnails in?". Getting rid of valid thumbnails should be possible, although it's not the main problem. The problem is: nautilus is using my hard disk space to store thumbnails which for one reason or another, I don't want. I don't want them for one of the following reasons: 1. The file they point to no longer exists 2. I don't use the removable media they point to any more 3. They point to valid files, but I just want the disk space back. On reflection, here's how I now think this should work: - (3) We need an option to set an upper limit on the size of the .thumbnails directory, defaulting to something sensible like 250MB. This should be enforced when new thumbnails are created - keep a track of how much space has been used, and when it's too much then delete the oldest thumbnails. - (1,2) Removing invalid thumbnails should happen without user attention, by nautilus getting rid of these thumbnails when it deletes or moves a file, and by a periodic scan for invalid thumbnails. Thumbnails with "/media/" or so in the path would be allowed to stay, as long as they did not exceed the .thumbnails size limit set above, and they're not more than say, 2 months old. - (3) Removing all thumbnails should remain a user option, since sometimes the user might not want thumbnails for a lot of files he still has (such as digital photos he no longer browses with nautilus). This should be a button in the nautilus properties dialog, and it should also be presented as an option when the "Low disk space" notification is shown. As such, perhaps it belongs in a seperate executable. Now all we need is for someone who doesn't have his final university exams next week to program it...
This problem needs to be solved in two parts. My solution, and a sensible fix to bug 141073. That's causing this to behave poorly because the disk cache has no expiry algorithm. If that were implemented, you wouldn't have to worry about 1 or 2, which would be reaped automatically given enough time. As for number three, you could turn down cache usage to get more disk space back.
I would still vote for having a button for clearing the cache, next to the setting for cache limit. Nevertheless, It's a moot point until the cache management stuff actually exists. Hopefully, someone will step up and write the necessary code reasonably soon. Otherwise, I would suggest committing my old patch, and then replacing that UI with the limit-setting stuff when it's ready (if ever). Not that I expect that to happen!
Setting patch status as "needs-work" as it doesn't apply cleanly anymore on SVN trunk. Also, some parts of bug #523159 could affect this.
Starting with gnome 2.23.x, the oldest thumbnails are purged shortly after login when the cache exceeds 64 MB, or if they are older than 60 days, so I'll close this bug as fixed. (You can re-open if you really object.) I don't think we want a manual purge tool in Nautilus - that violates the underlying keep-it-simple philosophy. - Mike