Skip Menu |

This queue is for tickets about the Image-ExifTool CPAN distribution.

Report information
The Basics
Id: 18615
Status: resolved
Worked: 30 min
Priority: 0/
Queue: Image-ExifTool

People
Owner: Nobody in particular
Requestors: bengh [...] xs4all.nl
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 6.00
Fixed in: 6.17



Subject: File extension is corrupted when using -FileName<DateTimeOriginal option and file has already the correct name.
While trying to rename files using ExifTool.bat an error occurs: files not to be renamed get an incorrect extension (%e). The problem occured on a Windows XP Home system (SP2 and latest patches) with ActiveState Perl V5.8.6 build 811, ExifTool version is 6.12. An example: the input is a directory named debug with two files: 09-04-2006 15:09 <DIR> . 09-04-2006 15:09 <DIR> .. 31-03-2006 13:39 2,415,733 20060331_133933.jpg 06-11-2005 16:59 6,746,338 will_be_renamed.CRW The md5sums: 0a619d0024e6f64401fd7f6684a36e9a *20060331_133933.jpg 658a0fce0b50233234df2554c7988758 *will_be_renamed.CRW The goal is to rename the files according to the DateTimeOriginal EXIF tag while keeping the orginal extensions. The command used is: exiftool -v5 -r "-FileName<DateTimeOriginal" -d %Y%m%d_%H%M%S.%%e debug This generates the following output: Setting new values from debug/20060331_133933.jpg Writing File:FileName + FileName = 'debug/20060331_133933.%e' Setting new values from debug/will_be_renamed.CRW Writing File:FileName 'debug/will_be_renamed.CRW' --> 'debug/20051106_155906.CRW' + FileName = 'debug/20051106_155906.CRW' 1 directories scanned 2 image files updated The result is: 09-04-2006 15:10 <DIR> . 09-04-2006 15:10 <DIR> .. 06-11-2005 16:59 6,746,338 20051106_155906.CRW 31-03-2006 13:39 2,415,733 20060331_133933.%e One of the files is renamed correctly, the other has now an incorrect extension. The files are not changed, md5sums: 0a619d0024e6f64401fd7f6684a36e9a *20060331_133933.%e 658a0fce0b50233234df2554c7988758 *20051106_155906.CRW A possible workaround is to use the -ext option together with multiple calls to ExifTool, but this is less efficient and one of the beauties of ExifTool is that it recognizes so many different file types by itself.
Thank you for this bug report. I have been able to reproduce this problem. It was exactly as you specified: The filename format codes weren't being expanded properly if a file with the correct destination filename already existed. This bug is fixed in ExifTool version 6.13, which I have just released from the ExifTool home page.