I created a csv file in Excel vba from a list of jpeg files, with two columns: SourceFile and DateTimeOriginal. One of the files has a percent sign in the filename "Test03-0%.jpeg". In a Windows cmd window, when I read the csv in exiftool to set the DateTimeOriginal tags on a directory of files, all the files are updated except Test03-0%.jpeg, which gives error:
Warning: Error opening file for update - ./Test03-0%.jpeg
Windows doesn't mind the filename, the file works in other programs, and the file is not in use elsewhere. I have read FAQ 18, tried putting the filename in quotes, tried adding additional characters to the filename so % is not the last character, tried -charset filename=utf8, tried csv file UTF-8 with and without BOM, but the error remains.
The error goes away if I remove the % from the filename - the file is processed normally like the others. If I put the % back in the filename, the error recurs.
Is this a known restriction in exiftool, or Windows 10 cmd? (why % in a filename? See background below)
Software: exiftool 13.10; Windows 10 22H2 (Country: Denmark, Regional settings: English UK)
Command line: (current directory in cmd same as where files are)
exiftool.exe -m -charset filename=utf8 -csv="Test03_DTO.csv" -overwrite_original -ext jpg -ext jpeg -ext png -ext tif -ext tiff .
Console output:
Warning: Error opening file for update - ./Test03-0%.jpeg
1 directories scanned
23 image files updated
1 image files unchanged (this is Test03-01.jpeg, with "na" in the csv file)
Top of file Test03_DTO.csv
SourceFile,DateTimeOriginal
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test03\Test03-0%.jpeg,1984:02:01 12:01:00
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test03\Test03-00.jpeg,1984:02:01 12:02:00
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test03\Test03-01.jpeg,na
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test03\Test03-02.jpeg,1984:02:01 12:04:00
...
Background: I have scanned photo prints to jpeg files, organized by the original rolls of 35mm film, for which I have the negatives. I want to use the frame number on the negative as two-digit sequence number on the jpg files. For example for roll "PN005" I have PN005-01.jpeg, PN005-02.jpeg, etc. In addition to giving a precise link back to the original negative, the sorting order of filenames retains the time sequence from the negatives, which helps when setting DateTimeOriginal for the scanned pictures.
However I often have prints at the beginning of the roll before frame 1, which may show as 0, 00, 000, X, or no frame number at all. PN005-00.jpg works fine for the first frame before 1, but there is a dilemma to number frames before "00" and still have a filename which remains in sequential order when sorted by name. Avoiding characters that are clearly not allowed in filenames, but using printable characters before "0" (digit zero) in ASCII, I arrived at "0$" and "0%" for the frames -2 and -1 before 00. This worked initially, but problems are surfacing. Exiftool apparently doesn't like the %, and Windows Explorer's "logical" sort order for filenames puts "0$" and "0%" between "00" and "01", not before them. ::)
I can't reproduce this here. Obviously, my paths have to be different, but the filenames and csv file are otherwise the same. This is with exiftool ver 13.11, but I don't think that should cause a problem.
C:\>type temp.txt
SourceFile,DateTimeOriginal
Y:\!temp\x\y\Test03-0%.jpeg,1984:02:01 12:01:00
Y:\!temp\x\y\Test03-00.jpeg,1984:02:01 12:02:00
Y:\!temp\x\y\Test03-01.jpeg,na
Y:\!temp\x\y\Test03-02.jpeg,1984:02:01 12:04:00
C:\>exiftool.exe -m -charset filename=utf8 -csv="temp.txt" -overwrite_original -ext jpg -ext jpeg -ext png -ext tif -ext tiff Y:\!temp\x\y\
1 directories scanned
3 image files updated
1 image files unchanged
C:\>exiftool -G1 -a -s -DateTimeOriginal Y:\!temp\x\y\
======== Y:/!temp/x/y/Test03-0%.jpeg
[ExifIFD] DateTimeOriginal : 1984:02:01 12:01:00
======== Y:/!temp/x/y/Test03-00.jpeg
[ExifIFD] DateTimeOriginal : 1984:02:01 12:02:00
======== Y:/!temp/x/y/Test03-01.jpeg
======== Y:/!temp/x/y/Test03-02.jpeg
[ExifIFD] DateTimeOriginal : 1984:02:01 12:04:00
1 directories scanned
4 image files read
There are times when there is a percent sign in the filename that matches one of the percent variables such as %d/%e/%f can cause some weirdness (see this post (https://exiftool.org/forum/index.php?msg=70896)) but in this case it would have to be a "%j" variable and there isn't one afaik.
Can you run a command directly with that file?
exiftool -DateTimeOriginal="1984:02:01 12:01:00" Test03-0%.jpeg
Also, is this with CMD or PowerShell (try CMD if PS)? And is it in a batch file (shouldn't be the problem, but asking just in case)?
There should be no difference in the file handling between 13.10 and 13.11.
ExifTool shouldn't care about any percent characters in the name of the file itself.
I don't understand how this could happen. Especially since it seems to work on another Windows system. What is the type of filesystem you are using? (NTFS, FAT32, exFAT?) I don't know if this could make a difference.
- Phil
Thanks StarGeek and Phil for looking at this.
I ran StarGeek's command line, in CMD:
C:\Users\...\Test03>exiftool -DateTimeOriginal="1984:02:01 12:01:55" Test03-0%.jpeg
Warning: Error opening file for update - Test03-0%.jpeg
1 image files updated
In spite of the warning, the file is updated (original file saved as Test03-0%.jpeg_original). (I changed the time slightly in the command, to be different than the existing DTO)
These files are in my Dropbox folder. The jpegs have been edited in Topaz Photo AI 3.4.1 (Macintosh), but renamed in Windows. I will try this with some other jpgs, not in Dropbox and not touched by Topaz....
I put 4 files in folder C:\Test04 (not dropbox) and renamed them:
1) "iPhone13pro-0%.jpg" A iPhone photo (iPhone to Windows via PhotoSync app)
2) "TopazMac-0%.jpg" A print scanned using Vuescan 9, but then denoised in Topaz Photo AI (Mac)
3) "Vuescan9-0%.jpg" A print scanned using Vuescan 9 (Windows)
4) "Test02-0%.jpeg" The file causing problems, identical to TopazMac-0%.jpg and Test03-0%.jpeg
Only iPhone13pro-0%.jpg and Test02-0%.jpeg have existing DateTimeOriginal.
First test: in CMD window a) read existing -DateTimeOriginal, and then b) update -DateTimeOriginal as suggested by StarGeek, and c) read -DateTimeOriginal. No errors.
Second test (files restored to original): in CMD window a) read existing -DateTimeOriginal, and then b) update via -csv, and c) read -DateTimeOriginal. No errors.
Third/fourth test (files restored to original): Copied the 4 files to subfolder of Dropbox directory, and repeated tests 1, 2. No errors.
The only remaining condition to test is that the problem first occurred on files that had been renamed by an Excel VBA script, and exiftool run using WScript.Shell. I will retry that tomorrow. Thanks for your input.
I just retried using a Dropbox folder, with the 4 files mentioned in my previous post, and StarGeek's command line. Here is the CMD console output:
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" Test02-0%.jpeg
Warning: Error opening file for update - Test02-0%.jpeg
1 image files updated
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" TopazMac-0%.jpg
Warning: Error opening file for update - TopazMac-0%.jpg
1 image files updated
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" Vuescan9-0%.jpg
1 image files updated
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" iPhone13Pro-0%.jpg
Warning: Error opening file for update - iPhone13Pro-0%.jpg
1 image files updatedOn dropbox, 3 of the 4 files give an error. The one that didn't give an error is a jpg created on Windows (Vuescan). The others were created on iPhone or Macbook. I have no idea why that should matter. ???
ps. Phil, the file system for C: is NTFS.
Ah, OK. Is some other process monitoring the dropbox folder? Or maybe dropbox keeps them open? Windows has the peculiarity (unlike all other operating systems) that opening a file from one application will block it from being written by another. This makes Windows an easy target for DOS attacks.
I don't know why this should preferentially happen to files with a percent in their name, but if my theory is correct than this would be a quirk of the software that is working with the dropbox files, and not due to ExifTool.
Maybe try adding -o SOME_OTHER_DIRECTORY to you command to write the output files to a different directory. Of course then you'll have to delete the originals yourself. I would have suggested trying -directory=SOME_OTHER_DIRECTORY -overwrite_original to move the files to a different directory when writing, except that I fear it would run into the same problem.
- Phil
Edit: But wait. All of the files were updated. I checked the code and the warning likely happens when ExifTool tries to set the filesystem times after writing the file. So these times may not be correct, but the file itself may have been written OK.
Thanks for the heads up regarding Dropbox, Phil - I can confirm that Dropbox is the culprit, and pausing sync in Dropbox eliminates the warning in exiftool.
Using one of the files that caused error before in a Dropbox subfolder, I ran the same commands with and without Dropbox sync paused several times. I manually paused and resumed sync via the Dropbox tray icon. Here is the CMD console output:
---------- Dropbox sync running normally --------------
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal Test02-0%.jpeg
Date/Time Original : 1984:01:01 10:00:00
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" Test02-0%.jpeg
Warning: Error opening file for update - Test02-0%.jpeg
1 image files updated
---------- Dropbox sync paused 30 minutes ---------------
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" Test02-0%.jpeg
1 image files updated
---------- Dropbox sync resumed ---------------
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -DateTimeOriginal="1984:02:01 12:01:55" Test02-0%.jpeg
Warning: Error opening file for update - Test02-0%.jpeg
1 image files updatedAs you can see, the warning only appears when Dropbox sync is running, but not when Dropbox sync is paused.
I also tried the -csv update the same way, with and without Dropbox sync running:
---------- Dropbox sync running normally --------------
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -csv=Test05_DTO.csv .
Warning: Error opening file for update - ./iPhone13Pro-0%.jpg
1 directories scanned
4 image files updated
---------- Dropbox sync paused 30 minutes ---------------
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -csv=Test05_DTO.csv .
1 directories scanned
4 image files updated
---------- Dropbox sync resumed ---------------
C:\Users\DRC\Dropbox\Pictures\prints\Excel\Test05>exiftool -csv=Test05_DTO.csv .
Warning: Error opening file for update - ./iPhone13Pro-0%.jpg
1 directories scanned
4 image files updatedAs before, the warning only appears (for one of the files) when Dropbox sync is running, but no warning when Dropbox sync is paused.
As you noted Phil, all the files get updated even when a warning appears, so it is not a critical issue. But pausing Dropbox briefly while running exiftool on files in Dropbox folders can avoid any doubts.
Why the "%" in the filename causes Dropbox sync to interfere with exiftool is a good question for Dropbox. I will see if anyone has encountered this issue in the Dropbox forum.
For information, Dropbox advises "Don't use special characters in file names" and specifically don't use /\<>:"|?*. or emojis (Dropbox help - File and folder name recommendations (https://help.dropbox.com/organize/file-names)). Windows doesn't allow these anyway. I suppose "%" is considered a "special character" by Dropbox.
I have also checked other "special characters" and confirm that "$", "#", "!", "+", "," and "^" in filenames in Dropbox folders cause the same warning to appear in exiftool as for "%" -- there are probably others. The carat "^" also requires the whole filename be quoted on the command line, because cmd.exe uses ^ as escape character and also as line continuation character. ::)
I can also report that the Dropbox API does not support pause or resume of syncing, so I am left with manually pausing Dropbox while running exiftool on Dropbox subfolders.
I need to rethink my negative-frame-number sequence numbering system for scanned print filenames. I will now try "+0" and "+1" for the -2 and -1 frames. At least they sort before "00" in Windows Explorer. Now to see if they cause other gotchas.