ExifTool hangs (caused by loop?) when renaming files using %2.4C and file exists

[FrankB]

Environment
Exiftool: 12.96
Windows 10 Pro

Steps to reproduce:
- Create a directory with 2 JPG's (File1.jpg and File2.jpg) with the same date in Exif:DateTimeOriginal.
- Execute this command to rename File1.jpg

exiftool -v0 -overwrite_original "-filename<${Exif:DateTimeOriginal} RenameTest%2.4C.%e" -d %Y-%m-%d File1.jpg

This will rename the JPG to <2024-09-04 RenameTest0002.jpg> (Or whatever date was in Exif:DateTimeOriginal)

- Execute the same command to rename File2.jpg

exiftool -v0 -overwrite_original "-filename<${Exif:DateTimeOriginal} RenameTest%2.4C.%e" -d %Y-%m-%d File2.jpg

This will cause ExifTool to hang. I think because it might be looping to find an unused filename.

Furter testing makes me believe that the problem occurs when the first file sequence nbr that ExifTool should try exists, but only when using %C (Uppercase), %c (lowercase) works fine.

Frank

[StarGeek]

I was able to narrow this down to version 12.57 (works) and 12.58 (doesn't).

From the version history

Fixed issue where the %C filename format code would increment the count on an output filename collision, but it is supposed to count the input files

Phil is away for a couple of weeks, so this will have to wait until he returns.

[FrankB]

I was able to narrow this down to version 12.57 (works) and 12.58 (doesn't).

Thanks.

Phil is away for a couple of weeks, so this will have to wait until he returns.

Forgot to mention: No hurry.

[Phil Harvey]

Sorry for the delay.

So it seems the proper response to your second command would be to fail with an error that the output file exists?

- Phil

[FrankB]

Hi Phil,

As I said: No hurry.

So it seems the proper response to your second command would be to fail with an error that the output file exists?

I think that will work, and I agree if that's your proposed solution.

But it's not what I expected. I had hoped that the second rename would rename <File2.jpg> in <2024-09-04 RenameTest0003.jpg> . So start with sequence number 0002 and increment until it finds a non-existing file. I must admit that that method can be time consuming.

Of course I had a look at the code how this can be done. I find this line suspicious. Exiftool.pl, sub NextUnusedFilename, line 4315

Code Select Expand

$seq = $wid + ($sign eq '-' ? $seqFileDir : $seqFileNum) - 1; 
$seqFileDir and $seqFileNum are never updated within that method. I have tried to define and initialize 2 new local variables and increment those, and that seems to work.

Code Select Expand

........
my $localDir = $seqFileDir -1;
my $localNum = $seqFileNum - 1;
for (;;) {


Code Select Expand

$seq = $wid + ($sign eq '-' ? $localDir++ : $localNum++); 
Happy with whatever you decide.
Frank

[Phil Harvey]

Hi Frank,

Thanks.

The original intent of %C was to give the number of processed files.  Older versions incremented this in the loop but then synchronization was lost with the processed file count.  The bug fix for this failed to anticipate file name collisions.

I agree with your preferred behaviour, but I'll have to think about it to see if there is a way to achieve this.

This bug is high priority for me because I don't want ExifTool to ever hang.

- Phil

[FrankB]

This bug is high priority for me because I don't want ExifTool to ever hang.

Agree 100%. That's most important.

I agree with your preferred behaviour, but I'll have to think about it to see if there is a way to achieve this.

Would be nice if it could be done. Not a big deal (to me) if it cant be done.

Notes:
- The documentation doesn't state (or better I cant find) what should be done in the event of an already existing file. So both solutions are acceptable.
- This is only my opinion, other users are entitled to theirs. But apparently nobody noticed until now.

[Phil Harvey]

I have a solution, and I'll try to improve the documentation (see bold text below):

            A special feature allows the copy number to be incremented for
            each processed file by using %C (upper case) instead of %c.  This
            allows a sequential number to be added to output file names, even
            if the names are different.  For %C, a copy number of zero is not
            omitted as it is with %c.  A leading '-' causes the number to be
            reset at the start of each new directory (in the original
            directory structure if the files are being moved), and '+' has no
            effect.  The number before the decimal place gives the starting
            index, the number after the decimal place gives the field width.
            To preserve synchronization with the processed file number, by
            default the copy number is not incremented to avoid file name
            collisions, so any existing same-named file will cause an error.
            However using a colon instead of a decimal point causes the
            number to be incremented to avoid collisions with existing files.

- Phil

[FrankB]

Sounds great Phil!

Looking forward to getting my hands on it. Thanks a lot.

Frank

[FrankB]

Phil,

Your solution in 12.97 works fine.

Thanks again,

Frank

[Phil Harvey]

Great.

- Phil