.thumbnails directory keep growing

Thanks for your bug, that's known upstream: http://bugzilla.gnome.org/show_bug.cgi?id=150483

I don't quite understand why this is a wishlist bug. What we have here is an application that basically runs amok and fills up the disc until there is no space left. There is no way to prevent this and it happens in *every* installation.

Furthermore, for the average user there isn't even an easy way to work around the problem. Even if they manage to determine
 1) where the diskspace goes
 2) which application is resposible
 3) whether the folder can safely be deleted
they still have to do this periodically and only on a "all or nothing" basis.

Am I missing something obvious or should this bug be *at least* have priority normal?

Because implementing new features is considered as a wishlist, there is a specification about running a tool to make space when required registered for hardy, you can read about it on https://blueprints.edge.launchpad.net/ubuntu/+spec/handling-full-disks

fixed upstream, thanks for reporting.

This bug was fixed in the package gnome-settings-daemon - 2.23.1.1-0ubuntu1

---------------
gnome-settings-daemon (2.23.1.1-0ubuntu1) intrepid; urgency=low

  * New upstream version:
    - Sound server startup based on GConf setting, even when esd is disabled
    - Added a new "housekeeping" plugin to set limits on the size and age of the
      thumbnail cache (lp: #37643)
    - Fix mismatched modifier maping between egg and GTK
    - Replace some custom functionality with stock GTK
    - Mark string for translation
    - Use G_DEFINE_TYPE instead of open-coding
    - Change data types to match glib, avoid using time_t
    - Add mapping for Gtk/Modules xsetting using GConf
    - Set GConf keys back to false if mousetweaks is not installed
    - Don't try to add grabas with invalid modifiers
    - Remove trailing newlines from messages since g_warning already takes care
      of those
    - Fix various leaks
    - Fix TYPE macro and remove unimplemented prototype
    - Add a special volume subclass for better support of IBM Thinkpad hardware
      volume buttons
    - Initialize inited_ok or behaviour is undefined when xkb setup fails
    - Continued attempt at making XKB setup and error handling a bit less arcane
      and crufty
    - Only use the built-in default for volume_step if we get an
      error from GConf, not just when the value is 0 which might be what
      the user wants
    - Adds a "threshold" property to the AcmeVolume class that denotes
      the minimum percentage required to actually affect the volume
    - Don't install any listeners or callbacks when XKB is not available
    - Remove excessive key grab logging
    - Make plugins deactivation work
    - Properly null-terminate g_build_filename
    - Turn into a daemon by default and make --no-daemon work
    - DBus API has been stable for a while;
      don't define DBUS_API_SUBJECT_TO_CHANGE anymore
    - Drop GConf backup for xkb
    - Extract some functionality used by several plugins into a separate
      shared helper library
    - Reset GConf keys when we can't launch the daemon
    - Updated translations
  * Sync on Debian
  * debian/control.in:
    - updated maintainer information
  * debian/gnome-settings-daemon.install:
    - install the xrdb files in the correct directory
  * debian/rules:
    - don't do timestamps change since this tarball has no issue

 -- Sebastien Bacher <email address hidden> Tue, 03 Jun 2008 15:46:21 +0200