In order to remove leftover thumbnails from bug 754671 and to not block the UI when users clear their private data, we'll rename the whole storage directory and remove it using the async file IO on a chrome worker. The approach is almost identical to what the file cache does when purging the whole cache.

Is there any target ETA for this cleanup operation? Given that the disk space tied to these old thumbnails is not growing any more, I guess this bug has no big priority, but from security perspective the old thumbnails should still be cleaned at some point (and the disk space freed).

Yes, I do have a patch for it in my queue. I need to clean it up and update it a little and will post it then.

Any progress here? Will this get done in Fx19 or will it get pushed to the next version?

Requesting tracking because, according to bug 819805, this affects nightly and aurora, and can result in multiple gb of thumbnails sitting around on disk.

Tracking for Nightly/Aurora then - a fix for this would be great. Tim does your work from 2 months ago still apply?

Here's the patch I was working on months ago. It unfortunately doesn't apply anymore. I think we probably need to start from scratch again and take the patch from bug 753768 into consideration. We might want to wait for that bug to land first.

You could also maybe follow the approach selected for bug 805466 (removing old update temp directories), where the workload was kept reasonably small by deleting max. 10 directories at a time. In the context of this bug, a similar approach could be to delete max. 10 second level directories (thumbnails-old/x/x/ ) or alternatively just one first-level dir (thumbnails-old/x/ with its 16 second-level dirs). This cleanup should not be postponed too long. The to-be-deleted old thumbnails will land in too many backups in between :-(

From talking with gavin in IRC: 16:41 @gavin> affected firefox 17 nightly and firefox 16 aurora users 16:41 @gavin> was fixed while 16 was on aurora Since this is not affecting new-to-Nightly/Aurora users and did not go forward into Beta there's nothing to track here.

(In reply to hannu.nyman from comment #8) > In the context of this bug, a similar approach could be to delete max. 10 > second level directories (thumbnails-old/x/x/ ) or alternatively just one > first-level dir (thumbnails-old/x/ with its 16 second-level dirs). Yes, that sounds like a good idea to me. We should use the new OS.File API for that. > This cleanup should not be postponed too long. The to-be-deleted old > thumbnails will land in too many backups in between :-( I unfortunately won't be able to tackle this for at least another 1.5 months. If anyone wants to jump in, please do.

Gentlemen, I was shook when I found though I could limit the cache to e.g., 50 megabytes via Preferences, there was still this monster thumbnails-old here on Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20130104 Firefox/19.0 Iceweasel/19.0a2 . With Firefox not running, may I do $ find .mozilla/firefox/*/thumbnails-old/ -delete with no harm to my computer as a temporary workaround?

Yes.

This two-year old bug might maybe be closed with either WONTFIX or EXPIRED, as it is almost two years since the extra thumbnails-old directory was created. Many/most affected users (who had used either nightly 17 or Aurora 16,) have probably cleaned their profile directories with other means during the two years. It would seem superflous to now add this cleanup functionality for an operation done 2 years ago.

I agree that after 1.5+ yrs we should just WONTFIX this. Anyone still hitting this problem can manually delete their files or use the profile reset feature.