Issues when overwriting RAW files

Started by lokatz, March 02, 2023, 11:21:59 AM

Previous topic - Next topic

lokatz

Not sure whether this is me screwing up somehow or ExifTool getting confused, but I am running into rather strange behavior I can make neither heads nor tails of:

I use ExifTool in stay-in-memory mode via an argsfile, here to overwrite individual tags.  The code is this for non-RAW files:

-Rating=[0..5]
-overwrite_original
[FILENAME]
-execute

respectively this for RAW files:

-Rating=[0..5]
-overwrite_original
[FILENAME]
-m
-execute

(-m serves to keep ExifTool from stopping the execution if a minor error occurs.)

The non-RAW version works fine across the board. I tested it with JPG, PNG, and TIF files.

The RAW version, however, only works with some file formats, such as CR3, NEF, RAF.  With ALL ARW and ORF files (tested this across several camera types) and with one CR2 file format (Canon EOS M5), however, it reports "1 files weren't updated due to errors" and delivers an "Error renaming temporary file to [FILENAME]".  This happens consistently.  I verified that none of the files are read-only.  I also checked the original files and found that of those files where the error occurred, some had no previous Rating tags, some had an XMP-xmp:Rating of 0 and some had a Sony:Rating makernote tag of 0.

Any idea what may be happening here? 

StarGeek

I'm assuming that you aren't actually writing "[0..5]" and only writing a single digit, correct?

Does this happen when you run the command directly on the command line?  Can you share one of these files?

Do you have any program running in the background that might be locking the files?  For example, an antivirus or backup program.  Is it local drive or network drive?
* Did you read FAQ #3 and use the command listed there?
* Please use the Code button for exiftool code/output.
 
* Please include your OS, Exiftool version, and type of file you're processing (MP4, JPG, etc).

lokatz

Thanks for your thoughts.

Quote from: StarGeek on March 02, 2023, 11:40:10 AMI'm assuming that you aren't actually writing "[0..5]" and only writing a single digit, correct?
Correct.

Quote from: StarGeek on March 02, 2023, 11:40:10 AMDoes this happen when you run the command directly on the command line?  Can you share one of these files?
Will check and confirm tomorrow.  (Getting late here...)

Quote from: StarGeek on March 02, 2023, 11:40:10 AMDo you have any program running in the background that might be locking the files?  For example, an antivirus or backup program.  Is it local drive or network drive?
None I know of, other than that the C# code wrapped around all this runs within Visual Studio.  Will test a standalone run tomorrow to exclude that as the source of the issue.  Already re-booted and tried immediately afterwards, with the same result.  Drive is local.


OS is Win 10, ExifTool version 12.52.  Forum editor says, at the bottom, "Use tt for exiftool commands/options, code for output.", by the way.  ;)

Phil Harvey

I ran your argfile (with Rating set to "2") on my test set of ARW images from all Sony cameras.  All files updated with no problems as long as I used the -m option, running on MacOS.

I agree with StarGeek that this is likely an AV interference.  Unfortunately, Windows is susceptible to DOS attacks like this.  On other systems it it possible to rename a file even if some other process has opened it.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

lokatz

#4
Thanks, this is all helpful.  I'll keep investigating what may be causing it. 

The fact that only certain file types are affected may give me a hint, as different formats undergo different types of processing (thumbnail extraction, conversion to JPEG, ...) in my program.

EDIT:  Just found the issue.  I use libraw.dll in my C# program to extract thumbnails from these images.  That DLL apparently does not release images after processing them, so I had to create a workaround.  Thanks again for your help!