Version: 1.0.0 (using KDE 4.3.2) OS: Linux Installed from: Mandriva RPMs This is a regression. Previously digikam preserved the creation date of images and videos downloaded from a digital camera. Now the creation date of the file is the real creation date of the downloaded file, and not the creation date of the file on the camera. Maybe this is a bug in kipi?
Please specify your camera model. gphoto2 camera or USB mass storage? Please note that the creation date is usually taken from the image's metadata and not from file system. Are you talking about creation or modification date, reading it from where in digikam?
As far as I know, this is broken since 0.11 release, I already taked with Gilles about this, but we found no solution at the moment. For me, regardless what camera model I use, the camera importer always has no date information present, as if it is not read somewhere...
This is for various Canon cameras (A80 and A95), so it's not using usb mass storage. If this current camera interface doesn't provide the date information, the EXIF DateTimeOriginal tag would probably be where you get the correct date from (with a fall back to DateTime if missing).
So you are talking about info in the camera ui, like right sidebar info and renaming features?
No, this is in the import performed by digikam (Import -> Cameras -> specific camera).
Yes, that's what I meant by camera UI. The date in digikam's main window, when the photos have been imported, are correct?
There is no "creation date of the file" under unix (linux). People (me not so long ago) usually think that the ctime info means "creation time" but in fact it is the "change time", the time the file inode was changed.
Apart from my questions in #4 and #6, see also comment 10 of bug #188855 to check if this a bug from your driver.
The date of the file on disk (type 'ls -l') does not match the EXIF date. The creation date in the Digikam UI is ok but the modification date is the download date. I tried the suggestions of https://bugs.kde.org/show_bug.cgi?id=188855#c10 $ gphoto2 --debug --debug-logfile=gphoto2_usb.log --port "usb:" --show-info 1 [snip] Information on file 'IMG_5793.JPG' (folder '/store_00010001/DCIM/257CANON'): [snip] Time: Sun Jan 17 14:07:22 2010 [snip] $ gphoto2 --port "ptpip:" --show-info 1 [snip] Time: Sun Jan 17 14:07:22 2010 [snip] But it is probably not necessary to attach the debug-logfile. As the modification date is set to: -rw-r--r-- 1 edward edward 2.0M 2010-01-21 21:20 IMG_5855.JPG this date is obviously where the problem lies. The modification date should not be the date of when I download from the camera, it should be the modification date of the file on the camera (which will be very close to the creation date). This should be seen as a simple file move action - the date should be preserved. As for the question of file date - i.e. creation date, access date, and modification date - I thought creation date and modification date were both kept on the EXT file systems and the access date was the one not used? The following demonstrates that this problem is only in Digikam and not in gphoto2. First: $ ls -alh IMG_5855.JPG -rw-r--r-- 1 edward edward 2.0M 2010-01-21 21:20 IMG_5855.JPG $ gphoto2 --list-files [snip] #63 IMG_5855.JPG rd 1970 KB 2272x1704 image/jpeg There is no file in folder '/store_00010001/MISC'. There is no file in folder '/store_80000001'. $ gphoto2 --get-file 63 libusb couldn't open USB device /dev/bus/usb/005/003: Permission denied. libusb requires write access to USB device nodes. libusb couldn't open USB device /dev/bus/usb/005/004: Permission denied. libusb requires write access to USB device nodes. Downloading 'IMG_5855.JPG' from folder '/store_00010001/DCIM/258CANON'... File IMG_5855.JPG exists. Overwrite? [y|n] y Saving file as IMG_5855.JPG $ ls -alh IMG_5855.JPG -rw-r--r-- 1 edward edward 2.0M 2010-01-17 16:24 IMG_5855.JPG $ Here gphoto2 has downloaded the file and preserved the modification date, the correct behaviour for camera downloads!
SVN commit 1079087 by mwiesweg: Set the mtime of a file downloaded from a gphoto2 camera to the mtime retrieved from the camera. CCBUG: 221457 M +17 -0 gpcamera.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1079087
Someone with a gphoto2 camera should test this before we can close the bug.
tested with my Sony A500 in PTP mode. It's fixed... Marcel, as you have a Sony DLSR too, just switch camera mode to PTP instead UMS in settings device. PTP require Photo2 driver... Gilles Caulier