Bug 137770

Summary: Digikam doesn't keep original unix rights when modifying comments/tags/rating
Product: [Applications] digikam Reporter: Fabien <fabien.ubuntu>
Component: Tags-CaptionsAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 0.9.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In: 0.9.0
Sentry Crash Report:
Attachments: Test image

Description Fabien 2006-11-23 12:57:47 UTC
Version:           0.9.0-svn (using KDE KDE 3.5.2)
Installed from:    Ubuntu Packages
OS:                Linux

Like some people complained about digikam overwriting the original image file, I thought they could just change unix right to ensure digikam (or any software) won't change the file.
I tested it, but it doesn't work...
And, I also saw that digikam rewrite the the file even if it doesn't modify it.

Digikam configuration : all options in metadata unset

I changed the file rights in the album to just read-only (0400) then started digikam.
If I try to assign a new comment/tag/rate to an image, digikam will write the file (with the same md5sum, but new date) with defaut umask rights (eg file will be 0644).

I think it should keep unix right intact, but also don't try to modify files that are  read-only and don't update file date when no modification is done.
Comment 1 caulier.gilles 2006-11-23 13:01:08 UTC
Fabien,

I think it's relevant of Exiv2 library witch digiKam pass the file path to perform changes in files metadata.

Try to do the same thing with Exiv2 command line tool.

Gilles
Comment 2 Fabien 2006-11-23 13:07:38 UTC
Yes, it's the case. I tried with exiv2 -M

But, is there any reason to try to modify the file if metadata are unset or if the file is read-only ?
Comment 3 caulier.gilles 2006-11-23 13:11:44 UTC
No of course. I will take a look.

Gilles
Comment 4 Fabien 2006-11-23 14:10:05 UTC
BTW, I will file a bug on exiv2's bts about that.
Comment 5 Fabien 2006-12-04 12:37:24 UTC
Problem in exiv2 is nearly resolved.
But, there's still the problem that digikam calls exiv2 to rewrite the metadata even if all metadata options are unset in the configuration...

This is what I get if the file is read-only and metadata unset :

digikam: Cannot save metadata using Exiv2 (/localhome/fabien/Digikam/Pictures/test10/img_3403.jpg: Failed to open file (w+b): Permission denied (13))
Comment 6 caulier.gilles 2006-12-04 13:19:53 UTC
Fabien, with a JPEG file in Read only, i cannot reproduce the problem here. 

I have set off all save options in Metadata setup page, (IPTC Actions and Common Metadata Actions groups), and no error message appear on the console. Note than Exif Actions do not change anything into metadata from Album Gui. The 'Set orientation tag to normal...' option fix Exif tag only using editor.

Of course, if i set on one of these options, the error message appear on the console, and in this case, it normal...

Gilles
Comment 7 Fabien 2006-12-04 14:36:22 UTC
Created attachment 18780 [details]
Test image
Comment 8 Fabien 2006-12-04 14:40:48 UTC
That's weird. I've attached an image file which produces the problem, just to be sure...
The problem occurs when I change the comment.
The version I'm using is the latest trunk svn (freshly compiled this morning).
When I unset all options in metadata, I get the error with read-only files. If files are in read/write, they are updated (new file date), but without modification (still the same metadata).

If I set the metadata, the files are correctly updated with the new comment...

I also tried to restart digikam, just to be sure, but still the same.
Comment 9 Fabien 2006-12-06 16:49:06 UTC
Gilles, I tried again to remove everything and recompiled trunk version of everything using the scripts I put on the website.
If I set a comment on a read-only picture, it's still the same result :
digikam: Cannot save metadata using Exiv2 (/localhome/fabien/Pictures/test04/img_3402.jpg: Failed to open file (w+b): Permission denied (13))

With this configuration in ~/.kde/share/config/digikamrc

[Metadata Settings]
IPTC Author=
IPTC Author Title=
IPTC Copyright=
IPTC Credit=
IPTC Source=
Save Date Time=false
Save EXIF Comments=false
Save IPTC Credits=false
Save IPTC Photographer ID=false
Save IPTC Rating=false
Save IPTC Tags=false


I'm ready to do some experiments, add more debug or anything else, but I don't know where to start...
Comment 10 caulier.gilles 2006-12-07 07:37:26 UTC
Fabien,

Witch chmod options you use to change file right before to test ? Give me an ls- l of your picture files...

Where do you try to add Comments on picture : from editor or album gui ?

Gilles
Comment 11 Fabien 2006-12-07 09:57:19 UTC
It's 0400 :
-r-------- 1 fabien fabien 1642429 2006-11-13 10:39 img_3402.jpg
-r-------- 1 fabien fabien 1506637 2006-12-06 17:58 img_3403.jpg


From the album gui, if I try to change :
- comment
- tag
- rating


I get this :

digikam: Cannot save metadata using Exiv2 (/localhome/fabien/Pictures/test04/img_3402.jpg: Failed to open file (w+b): Permission denied (13))
kio_digikampreview: Exif Orientation: 1
digikam: Dirty: /
digikam: Dirty: /test04


albeit all metadata options are unset...

It's the same behavior from the image editor

All tests made with ubuntu 6.0.6 (x86_32 and x86_64 on different PCs), using the latest svn version of digikam, digikamimageplugins, exiv2 and kipi-plugins (with the scripts I put on the website).
Comment 12 caulier.gilles 2006-12-07 13:34:11 UTC
Damned, i can reproduce it now... Strange...

3 ways : 

1/ I too wrong.
2/ I need vacancy.
3/ I'm beginneer.
4/ I need a liter of coffee.

I suspect 2/ (:=)))...

Fixed in digiKam with commit #611245
Fixed in kipi-plugins with commit #611248

Gilles
Comment 13 Fabien 2006-12-08 16:00:15 UTC
Thanks a lot Gilles, that's great :)
I'm sure christmas holidays will help (I hope you can take some holidays...) ;-)

It's ok for this bug, but... (yes I know, I'm a pain :)), there's still something strange about files that are updated (new file time) when you assign new comment, tag or rating to a picture *albeit* all metadata are unset.
I will open a new bug for that :)

Thanks again Gilles !