https://bugs.kde.org/show_bug.cgi?id=485469
--- Comment #2 from spiesant <metal...@gmail.com> --- > Why wouldn't you want to include the thumbnail database in a backup? It can > take a long time to recreate the thumbnail database from a network drive. Running backups is performed regularly, but restoring a backup (and thus recreating thumbnails) is extremely rare. It's a bit senseless to upload multiple gigs on a daily basis (and to retain gigs of versioned thumbnail dbs), just so that the unlikely event of a restore will be faster. Currently, every daily backup spends ~40% of the time on this single file, and 60% on all data for all other programs combined. When ultimately, this is just cache and isn't essential to be backed up at all. > Do we really want to complicate this further for other users with different > database locations? Having an option to configure a different location for cache doesn't really complicate anything for other users, as they're free to leave the default locations as-is. All it would need is a 2nd textbox on Configure->Database. If not explicitly changed by the user behavior could remain as current. > Most backup programs offer configurations to exclude files. It's true that some backup software lets you do this, but ultimately having just one single application that forces you to store its cache in its user data folder considerably complicates things. It's much cleaner (& more consistent with other software) to simply be able to separate cache and user data (I.e. On Linux, that's why we have separate cache vs local dirs in the homedir). I can elaborate into more detail in my setup if it's interesting, but suffice to say that working around this data layout does require exceptions and workarounds in more than just one application (I have mirroring/syncing/snapshotting setup in a few different ways, and this does create issues for all of them). -- You are receiving this mail because: You are watching all bug changes.
