Version: 1.0.0-beta2 (using KDE 4.2.4) OS: Linux Installed from: Gentoo Packages Some images (and all videos) do not have an embedded creation date. In the v0.9.x series the Created date and Last Modified date were picked up from the last modification date on the file. This is as good a guess as you could make. In v0.10.0 and later the Creation date adopted by Digikam is the current date and the last modified date is read from the modification time of the file. This leads to the ludicrous situation of all files of this type having a creation date that is newer (sometimes significantly newer) than the modification date and this can't be the right default state. This is a significant issue since the photos are sorted by creation date and not by modification date (Which is correct). Please restore the old behaviour. I make a point of using "cp -p" when I copy files precisely so this information won't be lost.
Tim, Using libkexiv2 from KDE 4.3 (or trunk), digiKam from trunk (1.0.0-beta3) will provide a new option in Metadata setup panel to ajust file time stamp when images are changed. This can help you ? Gilles Caulier
Well it can never be the right thing for Last Modified to be older than Created and 0.9.x did the right thing and on import set Created to Last Modified.
After some more investigation I think that something is assuming that the ctime field is the file creation time. It's not, it's the inode creation time. The problem is that if you use something like cp -p or mv the modification and access times are preserved but the inode creation time changes. I haven't been able to find the bit in the code where the file is stat()ed [I'm a C programmer not a C++ programmer] but what needs to happen is that the create date has to be the oldest of atime, ctime and mtime. I can have a go at a patch if someone can point me at the relevant file.
Is there any case where atime can be older than ctime or mtime? Shouldn't the latter two be enough?
SVN commit 996418 by mwiesweg: Use the oldest of ctime, mtime when falling back to the file system to determine the creation date CCBUG: 199967 M +16 -4 imagescanner.cpp M +1 -0 imagescanner.h WebSVN link: http://websvn.kde.org/?view=rev&revision=996418
Thanks. Works great once I realised that digiKam was clever enough to spot that it already had copies of all my test images and so was reading metadata directly from the database rather than from the file as I copied them in with new names!