Bug 199967

Summary:	Creation date newer than last modified date
Product:	[Applications] digikam	Reporter:	Tim Jenness <tim.jenness>
Component:	Metadata-Date	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	caulier.gilles, marcel.wiesweg
Priority:	NOR
Version:	1.0.0
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:	1.0.0
Sentry Crash Report:

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!