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
I was able to narrow this down to version 12.57 (works) and 12.58 (doesn't).
From the version history (https://exiftool.org/ancient_history.html#v12.58)
QuoteFixed 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.
Quote from: StarGeek on September 04, 2024, 02:15:20 PMI was able to narrow this down to version 12.57 (works) and 12.58 (doesn't).
Thanks.
Quote from: StarGeek on September 04, 2024, 02:15:20 PMPhil is away for a couple of weeks, so this will have to wait until he returns.
Forgot to mention: No hurry.
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
Hi Phil,
As I said: No hurry.
Quote from: Phil Harvey on September 22, 2024, 09:21:33 PMSo 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
$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.
........
my $localDir = $seqFileDir -1;
my $localNum = $seqFileNum - 1;
for (;;) {
$seq = $wid + ($sign eq '-' ? $localDir++ : $localNum++); Happy with whatever you decide.
Frank
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
Quote from: Phil Harvey on September 23, 2024, 07:07:28 AMThis bug is high priority for me because I don't want ExifTool to ever hang.
Agree 100%. That's most important.
Quote from: Phil Harvey on September 23, 2024, 07:07:28 AMI 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.
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
Sounds great Phil!
Looking forward to getting my hands on it. Thanks a lot.
Frank
Phil,
Your solution in 12.97 works fine.
Thanks again,
Frank
Great.
- Phil