When import photos change the date

[BigSus]

When I import photos in ubuntu dapper the date of the files is changed to the present date instead of the date in which I made the photography (libgphoto2-2)

[Simon Law (sfllaw)]

Reproduction steps:
1. Take a JPEG photograph with a digital camera.
2. Use a card reader to grab that photograph off the flash card. Call it A.JPG.
3. Connect the camera to the computer via USB and follow the wizard to download the photograph. Call it B.JPG.
4. Compare the timestamps of the two photographs.

Expected result:
A.JPG and B.JPG should have exactly the same timestamps.

Actual result:
A.JPG has a newer timestamp than B.JPG.

[Hubert Figuiere (hub)]

what camera do you have?

which version of libgphoto2?

[BigSus (bigsus)]

My camera is Kodak LS-743

The version included in Dapper

[Wolfram Riedel (taisto-web)]

I have the same problem with a Canon 800IS. The file dates/times loaded (PTP mode) are the current date and time, neither the exif stamps nor the dates/times from the files on the card. Same happens to thumbnails and raw format.

For a while now I kept/reinstalled those packages in dapper which don't show this bug:
libgphoto2-2_2.1.6-1ubuntu6_i386.deb
libgphoto2-port0_2.1.6-1ubuntu6_i386.deb
gphoto2_2.1.6-2_i386.deb

IIRC the bug showed up when updating to those package versions:
libgphoto2-2_2.1.6-5.2ubuntu8_i386.deb
libgphoto2-port0_2.1.6-5.2ubuntu8_i386.deb
gphoto2_2.1.6-2.1_i386.deb

Using edgy now these packages still have the bug:
libgphoto2-2 2.2.1-2ubuntu4
libgphoto2-port0 2.2.1-2ubuntu4
gphoto2 2.2.0-3

Tell me if I can get you any debug output.
Merci

[Martin Pitt (pitti)]

When you copy a file under Unix, the copy usually does get the current timestamp. However, the timestamp of a jpeg should be largely irrelevant, that's why photos have an EXIF tag. Programs like f-spot consider the EXIF date.

[Hubert Figuiere (hub)]

there is a weird bug were I have seen this happening. I don't know *where* it is, but it exists.

Yes, for reliable date information use EXIF.

[BigSus (bigsus)]

I already knew the existence tag EXIF.

I use nautilus and scripts made in python to organize my photographies.
In hoary he could see the date of creation of the files without the necessity of other program. Now I must remove the card from the camera and introduce it in a card reader to be able to continue having the date of creation instead of the one of copied date of the file that is not worth me for anything.

Thanks.

[Hubert Figuiere (hub)]

Python has some modules to read EXIF as far as I know.

[BigSus (bigsus)]

I know program with python but not a normal user.

Is dificult change it? Perhaps with a config file?

[Wolfram Riedel (taisto-web)]

When I copy files under unix I usually have the option '-a' to preserve permissions/time stamps. Until this bug (or has it now to be seen as a change of policy?) the timestamp of the file my cam produced was as reliable as the exif information. I organize my pictures by using a very short shell script that moves the files into directories accordingly to their time stamps. Since upgrading to edgy my workaround is using the old version's packages on a spare system and 'rsync -a'ing them to my main computer.

[Martin Pitt (pitti)]

In any way I do not see what libgphoto2 has to do with it. If you talk about usb-storage cameras, then you can of course copy files with 'cp -a'.

libgphoto2 only talks to the camers, thus the bug should be moved to gthumb/f-spot/whatever photo app you use for not preserving the file date.

[Hubert Figuiere (hub)]

Martin Pitt wrote:
> In any way I do not see what libgphoto2 has to do with it.

It has. Camera is Kodak LS-743. Kodak are NOT USB Mass Storage.

[BigSus (bigsus)]

In hoary it worked conserving the date of creation of the file. It was in dapper when this functionality was lost. I think that the problem is in libgphoto2

[Pierre Frenkiel (pierre-frenkiel)]

I arrived on this bug report via google, having the same problem with gphoto2 and my camera Canon 20d.
I found a woraround by applying the following script on all files after their download with gphoto2:

#!/bin/bash
F=$1
TT=`exif $F | grep 'Date and Time '|cut -d \| -f 2 | sed "s/:/ /g"`
[[ -z $TT ]] && exit 1
set $TT
print ..$TT..
touch -t $1$2$3$4$5.$6 $F

(exif may be installed with "aptitude install exif)
Nervertheless, I can't agree with the assertion that "the time stamp of the jpeg file is irrelevant"
It's usfull for example with "ls -t". And this feature is actually a bug introduced at least in the Ubuntu version,
as it was not present the Fedora Core 5 version I used before.

[Pierre Frenkiel (pierre-frenkiel)]

oops ... the line "print ..$TT.." must be removed from the script (wrong cut and paste ...)

[Pierre Frenkiel (pierre-frenkiel)]

After the upgrade to Gutsty, I crossed fingers when seeing many bug reports about
several cameras not detected. At least for mine (Canon 20d), all works fine (gphoto2, f-stop)
and I was happy to see that the bug about the date has been fixed.

[Wolfram Riedel (taisto-web)]

With gphoto2 under gutsy (gphoto2 2.3.1-5, libgphoto2-2 2.4.0-2ubuntu2, libgphoto2-port0 2.4.0-2ubuntu2) and Canon IXUS 800IS still the same bug here.

[Stephen on 3rd Rock (sonrock3)]

It's a permissions thing (assumign same problem as I've just solved in Ubuntu Gutsy gnome - I installed ntfs-config then enabled both options).

Good luck
Stephen

[Adilson Cavalcanti (carvalho-adilson)]

I have Gutsy (7.10), a camera Canon S3 IS and a card reader. Everytime Gutsy imports files, all files will assume date/time when they were copied to PC, not when the pictures were taken or the films were shot.

It happens when I connect my camera or a memory card (in my card reader). So, this bug is not related to any camera model

All the photos and films are copied into a NTFS partition.

I did a script to copy files from a memory card into this same NTFS partition using rsync and it DOES preserve date/time. So, this bug is not related to NTFS partition.

I fix all date/time from my pictures using this command in the photos directory:
jhead -ft *

On NTFS partitions, use: sudo jhead -ft *

It works for photos, copying the date/time from EXIF, but unfortunatelly it does not work for films (because films don't have EXIF info).

Bye!

[Crossland (rvarela)]

Ubuntu 8.04 with all patches included as of July 31'2008

Nautilus copy to a NTFS volume losses the timestamp of the file. Both "last modification date" and "last access date" are INCORRECTLY set in the destination file to the current timestamp (i.e. that of the copy operation).

Dates should be kept. Copy is NOT a modification.

This is similar to bug 215499 (already corrected for EXT3), but may have a different cause.

By the way, I'm synchronizing to my USB-Flash and with a NTFS volume, with a windows utility I had bought in my previous "W-life"(FSYNC), under wine, and it is working correctly. But not nautilus.

[Sebastien Bacher (seb128)]

seems to be known upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=1492476&group_id=8874&atid=108874

[Wolfram Riedel (taisto-web)]

It seems to be fixed in the karmic package.