Bug 207157 - Regression: Can't transfer EXIF creation date to file date
Summary: Regression: Can't transfer EXIF creation date to file date
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Generic-TimeAdjust (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-12 09:53 UTC by Kay Hayen
Modified: 2018-09-22 08:34 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.5.0
Sentry Crash Report:


Attachments
Screenshot of the function that fails (35.42 KB, image/png)
2009-09-12 10:52 UTC, Kay Hayen
Details
Checking that there actually is EXIF information available (54.04 KB, image/png)
2009-09-12 10:54 UTC, Kay Hayen
Details
Version information of kipi-plugin (28.31 KB, image/png)
2009-09-12 16:08 UTC, Kay Hayen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kay Hayen 2009-09-12 09:53:59 UTC
Version:           1.0.0~beta4 (using KDE 4.3.1)
OS:                Linux
Installed from:    Debian testing/unstable Packages

Hello,

digikam has an option to adjust the file date. I have used it to set the file date to the EXIF date with older versions of digikam and this was really a great thing to do. This feature alone sets Digikam apart from the rest and helped me improve my photo collection.

Now, I have imported images and the file date just doesn't get changed at all anymore. It remains day of import from the camera, while when I try to edit EXIF properties, I do see it has the date correctly. I think 2 months ago, I had the same problem.

Can you check if this is a regression of digikam that you can fix?

Thanks,
Kay
Comment 1 caulier.gilles 2009-09-12 10:46:01 UTC
>digikam has an option to adjust the file date. 

Which one exactly ? Please take a shot to explain where we need to fix regression

Gilles Caulier
Comment 2 Kay Hayen 2009-09-12 10:52:20 UTC
Created attachment 36884 [details]
Screenshot of the function that fails

Sorry for using German translation, but I hope you recognize it still. What this is supposed to do is to read EXIF creation date and touch the file date to this date. It doesn't.
Comment 3 Kay Hayen 2009-09-12 10:54:01 UTC
Created attachment 36885 [details]
Checking that there actually is EXIF information available

This is the dialog where I could edit the EXIF information. I didn't find a easier way to display it. The bug is not this dialog! This is only to show you that there actually is EXIF information in the file.
Comment 4 Kay Hayen 2009-09-12 10:59:10 UTC
I just notifced that the EXIF date is also display in the mouseover. The date that I actually want to change is in the thumbnail, where is says "Geändert: date" (likely "changed: date" in English.

But I checked with "ls -l" and "ls -l --time=ctime" that the file dates do not change at all. I was suspecting that Digikam might change ctime of the file and display mtime. But that's not the case.

Yours,
Kay
Comment 5 caulier.gilles 2009-09-12 12:04:35 UTC
Ok. It's not digiKam, but a kipi-plugins.

Dialog is an old version. Please update to last 0.6.0, or use current code from svn where improvements and fixes have been applied.

Gilles Caulier
Comment 6 Kay Hayen 2009-09-12 16:08:25 UTC
Created attachment 36896 [details]
Version information of kipi-plugin

Hello,

I updated it, but with no luck. I checked permissions of the files, but they should allow it. Digikam imported them itself earlier. 

Then I tried to not use EXIF at all, and used that option where you can specify the date, carefully disabling the checkboxes. Still no luck, the date doesn't change.

I tried with "strace digikam" and "strace -f digikam", but I somehow Digikam manages to escape. When trying to attach with strace to the running Digikam I get something funny when I attempt to start the plugin:

*** glibc detected *** strace: munmap_chunk(): invalid pointer: 0x000000000240e7a0 ***                                            
======= Backtrace: =========                                                                                                      
/lib/libc.so.6[0x30004716c8]                                                                                                      
strace[0x4083df]                                                                                                                  
strace[0x4058de]                                                                                                                  
strace[0x404616]
/lib/libc.so.6(__libc_start_main+0xe6)[0x300041e5c6]
strace[0x401f69]
======= Memory map: ========
00400000-00447000 r-xp 00000000 08:12 140312                             /usr/bin/strace
00647000-00648000 rw-p 00047000 08:12 140312                             /usr/bin/strace
00648000-00656000 rw-p 00000000 00:00 0
0240e000-0242f000 rw-p 00000000 00:00 0                                  [heap]
3000000000-300001d000 r-xp 00000000 08:12 776736                         /lib/ld-2.9.so
300021c000-300021d000 r--p 0001c000 08:12 776736                         /lib/ld-2.9.so
300021d000-300021e000 rw-p 0001d000 08:12 776736                         /lib/ld-2.9.so
3000400000-3000547000 r-xp 00000000 08:12 776742                         /lib/libc-2.9.so
3000547000-3000747000 ---p 00147000 08:12 776742                         /lib/libc-2.9.so
3000747000-300074b000 r--p 00147000 08:12 776742                         /lib/libc-2.9.so
300074b000-300074c000 rw-p 0014b000 08:12 776742                         /lib/libc-2.9.so
300074c000-3000751000 rw-p 00000000 00:00 0
3005e00000-3005e1a000 r-xp 00000000 08:12 776950                         /lib/libgcc_s.so.1
3005e1a000-3006019000 ---p 0001a000 08:12 776950                         /lib/libgcc_s.so.1
3006019000-300601a000 rw-p 00019000 08:12 776950                         /lib/libgcc_s.so.1
7fc6100f2000-7fc6100f4000 rw-p 00000000 00:00 0
7fc610118000-7fc61011b000 rw-p 00000000 00:00 0
7fff1617e000-7fff16193000 rw-p 00000000 00:00 0                          [stack]
7fff161c1000-7fff161c2000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

So please advise. Can you reproduce the error?

Yours,
Kay
Comment 7 Andrzej 2009-12-07 01:29:17 UTC
the bug is still present in kipi-plugins 0.9.0

The windows layout is changed but it still doesn't work.
I use:
Use Time & Date * EXIF/IPTC/XMP
Update Time & Date v File last modified

When I click "OK" there is some activity of my HDD  but then a message appears:

"Unable to update file modification time in:
file1.jpg
file2.jpg
file3.jpg
"
Comment 8 Andrzej 2009-12-07 01:46:21 UTC
OK.
I know what is the problem:
Apparently this plugin has problems with national characters e.g.
I had to change the directory name from "zdjęcia" to "zdjecia" in order to make it work.
Comment 9 caulier.gilles 2011-12-20 13:06:05 UTC
Kay,

This file still valid using kipi-plugins 2.4 ?

Gilles Caulier
Comment 10 Kay Hayen 2011-12-21 08:01:14 UTC
Hello Giles,

in digikam 1.9.0 I cannot reproduce it anymore.

Yours,
Kay
Comment 11 Andrzej 2012-01-12 23:24:48 UTC
still present in 2.4.1 when national characters are in path to a photo.

How can I reopen this bug?