Exiv2

I think (and Andreas will say if I am mistaken) the code opens a file with a call fopen(filename,"rb"). If you decide to write to the file, the code does an freopen to enable writing and will throw if unable. So you can open a readonly file. There is no API to say "open, but throw if I attempt to write". Of course a windows-readonly (or unix-without write permission) file would have that characteristic and throw when you attempt to write.

C:\Users\rmills>exiv2 -pt R.jpg | grep Original
Exif.Photo.DateTimeOriginal Ascii 20 2010:12:27 11:24:37
C:\Users\rmills>attrib +r R.jpg
C:\Users\rmills>exiv2 -pt R.jpg | grep Original
Exif.Photo.DateTimeOriginal Ascii 20 2010:12:27 11:24:37
C:\Users\rmills>exiv2 ad -a 0:0:1 R.jpg
Exiv2 exception in adjust action for file R.jpg:
R.jpg: Failed to open file (w+b): Permission denied (errno = 13)
C:\Users\rmills>attrib -r R.jpg
C:\Users\rmills>exiv2 ad -a 0:0:1 R.jpg
C:\Users\rmills>exiv2 -pt R.jpg | grep Original
Exif.Photo.DateTimeOriginal Ascii 20 2010:12:27 11:24:38
C:\Users\rmills>

Can you explain your purpose/intent/use-case please? And suggest an API to meet your needs.

Robin

The Exiv2 Image API is simple and makes file mode transparent to the user; essentially there are only two methods that access a file: Image::readMetadata and Image::writeMetadata. Under the hood the Exiv2 IO wrappers (BasicIo et al) determine the required file mode and switch automatically, as Robin said.

Andreas

Thanks for the replies.

I used the sample easyaccess-test.cpp from the src distribution and strace certainly showed that the open(2) calls were made with RDONLY. However, I wondered whether if there could be an extn to the i/f so that if an user wanted RDONLY access on a file, then we can be guaranteed.

At the moment, it appears that we are saying:

• request a file open, it's automatically openned as RDONLY
• if you make a modification call, file is reopenned with RDWR

To put some background on what I am doing, I am writting a small library/tool that will allow me to catalogue a bunch of images (jpegs/tiffs/Nikon NEFs etc) on a local rd/wr filesystem, generating a html table, with thumbnails of the images and basic image info (exif data: camera/lens/fstop/exposure/comments etc). The intention for this html table, along with the catelogued images will be written to DVD. The html table/images/exif info will be used as an index to the images DVD.

As the cateloguing with be the LAST step before burning the disk, the images will NEVER be updated again before burning. This means I will want to ensure that I/someone else using my library/tool will not inadvertently upd the images files by mistakenly calling an exif mod call (remember, developers are stupid and it's up to us as designers from preventing them misusing the library).

Therefore, I would like to ensure that when I open a file with the exiv2 library, that I can guarantee that there will be no updates possible with the handle I have just created.

Would be interested to hear you thoughts.

As I say, I have a work around (open(RDONLY), read() all data to internal buf, use ImageFactory::open() on my internal buf) but this seems to unneccessary and this RDONLY/no mod to underlying data should be provided by the exiv2 i/f itself.

Ray

Ray

Once you have finished updating the image, make it read-only on the file system. That's much better than changing the API because it prevents image modification. If we modify the API, that doesn't make the image safe because the developer can open another "handle" on the image and modify it. Fix this from the outside - it's not a library issue.

Robin

Robin,
what you are suggesting isn't really a fix, its a workaround. Consider:

If you had a txt file on your FS with r/w permission but you wanted to open this readonly, then you would request your editor to open this readonly ("vim -R" for example) - you would NOT: chmod to remove wr permission, view, chmod to reinstate wr permission.

This is what you are suggesting. Your objection to modifying the API (checking rdonly and throwing exceptions) already exists. Consider a simple image file, and the exifcomment sample program.

 $ chmod 400 /tmp/img.jpg
 $ ./exifcomment /tmp/img.jpg
 Writing user comment 'An ASCII Exif comment added with Exiv2' back to the image
 Caught Exiv2 exception '/tmp/2010.jpg: Failed to open file (w+b):  (errno = 13)'

So the actual i/f doesnt change (aside from the ImageFactory::open() allowing to specifiy RDONLY).

what you are suggesting isn't really a fix, its a workaround

I don't see the bug. There is nothing to fix. The high-level Exiv2 API is so simple that it doesn't need a file mode:
If you don't want to modify a file, don't call Image::writeMetadata().

Andreas

I have no idea why this forum topic has reappeared at the top of the stack. So, I'm updating simply so that it appears answered.

Happy New Year to all Exiv2 Contributors.

Robin