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.