Exiv2

I'd agree with the complaint about changed access rights. But the notion of "respecting UNIX file rights" is strange. The system must enforce these settings.

And I can't reproduce this (tried with exiv2-0.10 and SVN Rev 993)

When run as user ahuggel:

drwxr-xr-x 2 ahuggel ahuggel 4096 25-Nov-06 ./
drwxr-xr-x 8 ahuggel ahuggel 8192 25-Nov-06 ../
r------- 1 ahuggel ahuggel 4823 25-Nov-06 exiv2-empty.jpg
ahuggel@mowgli> ../exiv2 -M"add Iptc.Application2.Credit String Fabien" exiv2-empty.jpg
Exiv2 exception in modify action for file exiv2-empty.jpg:
exiv2-empty.jpg: Failed to open file (w+b): Permission denied (13)

When I switch to root user, I can write the file (as expected), but the permissions remain the same:

ahuggel@mowgli> su root
Password:
mowgli:/home/ahuggel/src/exiv2/src/tmp# ../exiv2 M"add Iptc.Application2.Credit String Fabien" exiv2-empty.jpg
mowgli:/home/ahuggel/src/exiv2/src/tmp# ls -la
total 36
drwxr-xr-x 2 ahuggel ahuggel 4096 2006-11-25 18:54 ./
drwxr-xr-x 8 ahuggel ahuggel 8192 2006-11-25 18:49 ../
-r------- 1 ahuggel ahuggel 4865 2006-11-25 19:09 exiv2-empty.jpg
mowgli:/home/ahuggel/src/exiv2/src/tmp# ../exiv2 -pi exiv2-empty.jpg
Iptc.Application2.Credit String 6 Fabien
mowgli:/home/ahuggel/src/exiv2/src/tmp#

Please provide more info:

-platform info
-exiv2 version
-ls -la `which exiv2`
-the user who is running exiv2 in your example

...

-ahu.

I did more tests about that.

I reproduced the bugs on 2 systems :
- dual-opteron (dual core) with linux x86_64 bit (ubuntu 6.0.6)
- Athlon 64 with linux x86_32 bit (ubuntu 6.0.6)

I tried with svn rev 992 and rev 994.

But, on a 3rd system (Intel Pentium m x86_32), it works as expected...
What I could see using strace is that on the systems where there is the bug, a new file is created, then the old file is removed and new is renamed.
I can't make more tests now, but I will give more informations in a few days...

What you saw in the strace is right. This is how the modified file is written.
I'll release 0.12 without this, but I'm still interested in what's wrong here.
My tests were done on an Intel Pentium D dual core machine running Debian testing
ahuggel@mowgli> uname -a
Linux mowgli 2.6.15-1-686-smp #2 SMP Mon Mar 6 15:34:50 UTC 2006 i686 GNU/Linux

Ok, I think the problem is related to the image file.
I attached 2 files :
- img_3522_overwrite.jpg which is the original file
- img_3522.jpg which is a part of this file (cropped and saved with showfoto).

On the original file, the bug is present, but not with the 2nd file (produced by showfoto)...

I added 3 files, output of strace :

- strace_img_3522 => with img_3522.jpg in mode 0400
- strace_img_3522_in_rw => with img_3522.jpg in mode 0644
- strace_img_3522_overwirte => with img_3522_overwrite.jpg in mode 0400

Indeed, with img_3522_overwrite.jpg I can reproduce the problem.

The problem occurs for files >1 MB (up to 1MB exiv2 uses a memory buffer for the temporary image, > 1MB a temporary file)

r999

I tested the latest svn version (rev 1006), and this is what I get :

$ ~/myopt/bin/exiv2 -M"add Iptc.Application2.Credit String Fabien" img_3403.jpg
Exiv2 exception in modify action for file img_3403.jpg:
img_3403.jpg: Failed to open file (w+b): Permission denied (13)

It looks ok, but a temporary file is created and not removed :

$ ls l
total 2946
-r------- 1 fabien fabien 1506574 2006-12-04 12:00 img_3403.jpg
rw-r--r- 1 fabien fabien 1506574 2006-12-04 12:00 img_3403.jpg16144

Delete temporary file if user does not have write permissions. (It would be better not to write the temporary file in the first place but that leads to other issues.)

r1007