Bug 199967 - Creation date newer than last modified date
Summary: Creation date newer than last modified date
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Date (show other bugs)
Version: 1.0.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-13 07:46 UTC by Tim Jenness
Modified: 2017-08-12 06:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Jenness 2009-07-13 07:46:36 UTC
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.
Comment 1 caulier.gilles 2009-07-13 23:48:25 UTC
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
Comment 2 Tim Jenness 2009-07-14 00:06:23 UTC
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.
Comment 3 Tim Jenness 2009-07-14 09:11:11 UTC
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.
Comment 4 Marcel Wiesweg 2009-07-14 12:21:04 UTC
Is there any case where atime can be older than ctime or mtime? Shouldn't the latter two be enough?
Comment 5 Marcel Wiesweg 2009-07-14 12:27:31 UTC
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
Comment 6 Tim Jenness 2009-07-15 09:01:54 UTC
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!