In EXIF, I don't allow the stored value to have zero length because I believe this goes against the EXIF spec (but I would have to look this up again to be sure). This goes for all EXIF "string" format tags. Some "undef" tags have a header identifying the character encoding which allows a zero-length value to be written: Since the header is always, stored, the stored value is never zero length.

The command-line interface doesn't allow you to set a tag to an empty value because this is the syntax for deleting a tag. The API, however, will allow a zero-length tag to be written if it is valid for the information type. (And as I said, this is not valid for EXIF "string" tags.) So empty values can be copied if they are valid. Also, sometimes a tag will look empty if it contains just spaces, so you have to keep this in mind too.

The -P option only preserves the filesystem date/time for a file, and has nothing to do with the writing strategy for the file. The in-place option actually writes over top of the original file instead of renaming a temporary file to replace the original. So in the end you have a modified copy of the same file, which makes a difference on some filesystems such as the Mac which may have icon information, etc associated with a specific file.

I hope this all makes a bit of sense.

- Phil

Hi Bogdan,

I didn't have a 50D CR2 handy when I wrote my last response, but I checked and you are correct. However, I forgot about the terminating null character that is written to EXIF string values. So a zero-length string is stored as one byte, and this should be allowed. I checked my code, and I was testing before adding the required null terminator. Technically maybe I should fix this -- I have to think about this a bit more.

The -overwrite_original_in_place option preserves most things, but the file modify date will certainly change (although the creation date won't). The -P option preserves the file modify date.

The -P option is fast, but the -overwrite_original_in_place option is slow.

- Phil