Bug 195202

Summary: thumbnail rename fails (cross-device link) and so cache doesn't work
Product: [Applications] digikam Reporter: Jonathan Marten <jjm>
Component: Thumbs-ImageAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 1.0.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 1.0.0

Description Jonathan Marten 2009-06-04 14:12:10 UTC
Version:           0.11.0-svn (rev.: 968562) (using Devel)
OS:                Linux
Installed from:    Compiled sources

Image thumbnails are generated initially to a temporary file, using KTemporaryFile.  This places the thumbnail in a path of the form:

  /tmp/kde-USER/MD5-digikam-?PID.png

These are then intended to be saved in the user's freedesktop standard thumbnail directory, ~/.thumbnails/large or ~/.thumbnails/normal.  Digikam attempts to do this by a simple rename in  ThumbnailCreator::load(const QString& path):

    if(savedCorrectly)
    {
        int ret = 0;
        Q_ASSERT(!tempFileName.isEmpty());

#if KDE_IS_VERSION(4,2,85)
        // KDE 4.3.0
        ret = KDE::rename(QFile::encodeName(tempFileName),
                          QFile::encodeName(thumbPath));
#else
        // KDE 4.2.x or 4.1.x
        ret = KDE_rename(QFile::encodeName(tempFileName),
                         QFile::encodeName(thumbPath));
#endif

        if (ret != 0)
        {
            kDebug(50003) << "Cannot rename thumb file (" << tempFileName << ")" << endl;
            kDebug(50003) << "to (" << thumbPath << ")..." << endl;
        }
    }

Unfortunately the rename() will not work if the temporary file and the destination thumbnail are on different file systems, which will typically be the case on any sensible installation.  On digikam's stderr output each thumbnail generates a message such as:

digikam(28782)/digikam (core) Digikam::ThumbnailCreator::load: Cannot rename thumb file ( "/tmp/kde-jjm/35f7885fd5af2a4371b9ce90855e38a2-digikam-J28782.png" )
digikam(28782)/digikam (core) Digikam::ThumbnailCreator::load: to ( "/home/jjm/.thumbnails/large/35f7885fd5af2a4371b9ce90855e38a2.png" )...

The effect for the user is that switching between folders and albums is very slow, because the thumbnails need to be regenerated every time.  Another side effect is that /tmp fills up with thumbnail files that are never deleted.
Comment 1 caulier.gilles 2009-06-04 14:18:23 UTC
Andi,

Well, it work for you ?

Jonathan,

With Andi, we have already hacked this issue and fixed it with current implementation from svn. I'm so surprised...

Gilles Caulier
Comment 2 Jonathan Marten 2009-06-05 11:11:32 UTC
Works for me now with current trunk.

Thanks for responding so quickly and pointing me to the fix - and great work, as always, from the digikam development team.  A high quality and amazingly useful application, and great support.

I will now cut and paste 1000000 times, "I will check SVN before submitting a bug"...
Comment 3 caulier.gilles 2009-06-05 11:22:18 UTC
Thanks for your feedback and your support. it's very appreciate...

Note : we working on a new thumbs storing way now: 

- Using another sqlite DB (dedicated for thumbs).
- Storing image using PGF format (wavelets based : www.libpgf.org). size optimization.
- We lost freedesktop paper. This will work with removable media as DVD for ex. for backup purpose
- More faster to render/show thumbs : PGF is very optimized against PNG format currently used.

See this entry for details :

https://bugs.kde.org/show_bug.cgi?id=191494

Gilles Caulier