Need help with charset FILENAME=

[Mac2]

I see to have misunderstood the functionality of this new feature.

A file is stored in a folder with a name containing German umlauts. The file name consists of German umlauts.
I created an arg file and stored it UTF-8 encoded:

-overwrite_original_in_place
-charset
ExifTool=UTF8
-charset
FILENAME=UTF8
-m
-use
MWG
-XMP-xmp:Label=Green
-XMP:MetadataDate=now
-XMP:ModifyDate=now
c:\images\JPG\Allgäu\äöü.jpg

When I run this args file, ExifTool reports the following error:

Error opening c:/images/JPG/Allg├ñu/├ñ├Â├╝.jpg for writing

I assumed since the entire args file is UTF-8 encoded, the file name is too? And the new -charset FILENAME=UTF8 option tells ExifTool to use that?
What would be the right way to do this?

[Phil Harvey]

I see nothing wrong with this (although the -charset exiftool=utf8 is unnecessary).  Try getting ExifTool to write the filename to see what you get:

exiftool -r -p "$directory/$filename" c:\images\JPG > out.txt

You should then be able to read this back in with

exiftool -charset filename=utf8 -@ out.txt -filename

- Phil

Edit:  Wait.  I wonder if there may be a problem with -overwrite_original_in_place on Windows.  I can't test this right now myself.  Perhaps you could look into this?

[Mac2]

Ah, that was a good guess.

Without -overwrite_original_in_place it works!
It works with -overwrite_original too.

[Phil Harvey]

OK, thanks.  I'll fix this before the next release.  Glad to have caught it just in time -- I plan to do a release tomorrow.

- Phil

[Mac2]

As always, thanks for your great work!

[Phil Harvey]

Version 9.90 is now available, and should solve this problem.

Thanks for reporting this.  You would be a top contender if there was a prize for the person who found the most bugs in ExifTool.

Keep up the good work!

- Phil

[Mac2]

Version 9.90 is now available, and should solve this problem.
Thanks for reporting this.  You would be a top contender if there was a prize for the person who found the most bugs in ExifTool.

Thanks, but not I found it, a user of my software reported the problem! 

I was, regrettably, in a hurry to ship an update, and thus did not test the new feature with a combination of non-ASCII file names, -overwrite_original_in_place and a drive where 8.3 file names are disabled. This combination is what revealed the glitch...