I recently realized that I do not yet have a satisfactory procedure in my application for distinguishing between errors and warnings. The triggering example was the following:
Command:
D:\Fotos\2015\StefanL\2015-04-26 13.13.01.jpg
-1IFD1:7ID-Exif-ThumbnailImage:ThumbnailImage=
-overwrite_original
-execute4
StdOut:
0 image files updated
1 files weren't updated due to errors
StdErr:
Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - D:/Fotos/2015/StefanL/2015-04-26 13.13.01.jpg
Error: Bad format (52562) for IFD0 entry 11 - D:/Fotos/2015/StefanL/2015-04-26 13.13.01.jpg
First: What do I mean by Error/Warning
I would define an error as when at least one action could not be executed, i.e. there was no fallback that could be used to fix the situation after all. This should essentially coincide with the philosophy of the ExifTool messages, as well as in this example. Warnings are logged but are not normally reported to the user. Errors must be reported to the user.
My guess is that parsing the text in StdOut might be the most sensible procedure. Can I rely on this format for write calls:
x image files updated
y files weren't updated due to errors
Also: Does my procedure for Read calls (s.a.) make sense?
I would be very happy to receive suggestions.
Cactus
Errors prevent the file from being written. Warnings don't. But I thought that should be obvious from the summary message, so perhaps I'm not understanding what you are asking.
- Phil
My primary concern is: Can I rely on this pattern for write calls or are there exceptions?
x image files updated
y files weren't updated due to errors
Jürgen
You can rely on that pattern.
- Phil
Just in case you haven't seen it, there is the -efile option (https://exiftool.org/exiftool_pod.html#efile-NUM-ERRFILE) to save the filenames of files causing errors.
Thanks a lot, guys! I hadn't noticed the efile option yet. Currently I only offer the option for updating one file, if I will enable more, this will be very helpful.
Cactus
I found an exception:
0 image files updated
1 image files unchanged
Are there more?
Cactus
Exactly what do you mean by "pattern"?
The text of each summary line always follows the same pattern.
There are a number of different summary lines which may appear. Perhaps the C++ interface GetSummary() documentation (https://exiftool.org/cpp_exiftool/index.html#GetSummary) is the best place to go for a list of these.
- Phil
Many thanks, this helps a lot. Excuse my misleading English.
Btw: I use my own C++ interface because I didn't want to complicate the installation procedure with cygwin.
If I have seen correctly, "Unchanged" also indicates errors. I was worried that setting a tag to the same value would also be considered unchanged, but this does not seem to be the case, this case is reported as "Updated". Can I rely on this?
Cactus
Hi Cactus,
The only tag that reports "Unchanged" if you write the same value is FileName. All others don't compare with the existing value when writing.
- Phil
Thanks, Phil, writing FileName is not an issue.
But I'm still fighting with error handling. I suspect that the summary is missing if -b is specified. Examples
exiftool file.JPG -artist=xxx -b
exiftool file.JPG "-ThumbnailImage<=thumbnail.jpg" -b
In this case there is no "1 image files updated". Is there a reason for this?
Cactus
Addendum1:
After I published this post, I checked the documentation again to see what the -b tag actually means when writing tags. I can't find any. I can't remember exactly why I decided to use it, possibly because I always use it when reading tags to file (saving the tag content to file) and I wanted to use it symmetrically.
Cactus
Addendum2:
I think I have found my reasons: If -b is used when reading a tag, the internal (num, suffix "#") value is implicitly used, if there is one. I had now assumed that the internal value is also used for -b when writing tags, even if the suffix "#" is not specified.
Cactus
Hi Cactus,
The -b option was never meant to be used when writing.
- Phil
Hi Phil,
that's fine, I add suffix "#" when writing to be symmetricial to my reading with "-b".
According to my tests, it doesn't matter if the suffix "#" is specified and there is actually no difference between internal and formatted format. If -b is nevertheless specified when writing, I would not mind an error message. The fact that it simply causes a missing summary is strange and initially led me on the wrong track, as I thought the missing summary was caused by reading the tag value from the file.
Cactus
For binary data tags, adding "#" makes no difference. The only difference is when reading a file you get the actual data instead of the "(Binary data XXXXX bytes)" string.
There are many options combinations that don't make sense, and it would be a LOT of work to add warnings for all of them.
- Phil