Exiftool 13.07 not saving files with names containing letter ø windows

Started by OMU1994, December 14, 2024, 01:32:04 PM

Previous topic - Next topic

OMU1994

Exiftool 13.07 Windows 64-it version used in Geosetter_beta 4.0.49 with the exiftool option -charset filename=Latin

Files with names containing ø on windows 11 24H2 cause an error when saving. The error is "file not found".
The letter ø (alt -155 on numeric keyboard) is a legal character in the cp1252 (Latin) character set.

After downgrading to Exiftool 13.06 Windows 64-bit version this error is not present any more.

The filename offending was "Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Meløyfjord mit Inseln Meløya und Bolga 2024-08-13_1078.jpg"

This works in 13.06, but not in 13.07.

After removing ø the name is "Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Melyfjord mit Inseln Melya und Bolga 2024-08-13_1078.jpg". This name works with 13.07, the file is saved .

Thanks for the otherwise great program

FrankB

I have tried to reproduce this in ExifToolGUI with ExitTool 13.07

!3.07 with -L gives an error, without -L works fine.

Could it be that GeoSetter uses -L by default, and if yes can you tell GeoSetter not to?

GUI with -L

minusL.jpg

GUI without -L

nominusL.jpg

StarGeek

Quote from: FrankB on December 14, 2024, 02:20:58 PMCould it be that GeoSetter uses -L by default, and if yes can you tell GeoSetter not to?

Yes, Geosetter does use the -L (latin) option. After writing to a file, the Edit Menu->Show Save Report shows the contents of the args file that was used.

There's no option to turn it off as far as I can tell. The language code options appear to apply setting the IPTC:CodedCharacterSet.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype

Phil Harvey

Frank, could you test to see if this patch to ExifTool.pm at line 4717 at fixes things?:

replace this

        my $enc = $$self{OPTIONS}{CharsetFileName};
        my $encPath = $self->Encode($longPath, 'UTF16', 'II', $enc);# need to encode to UTF16

with this

        my $enc = $$self{OPTIONS}{CharsetFileName} || 'UTF8';
        my $encPath = $self->Decode($longPath, $enc, undef, 'UTF16', 'II');# need to encode to UTF16

Thanks.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).


FrankB

Hi Phil,

That fix works only partially. ExifTool can read, and supposedly, write to the file. But the data it returns for '-filename' is not 'UTF8 proof'.

Without -L it returns:
File Name                       : Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Meløyfjord mit Inseln Meløya und Bolga 2024-08-13_1078.jpg

With -L it returns:
File Name                       : Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Mel�yfjord mit Inseln Mel�ya und Bolga 2024-08-13_1078.jpg

But that could be because my Windows is not configured properly for that codepage.

Frank


Phil Harvey

Thanks Frank.

Most important is that it opens the file.  I'll go ahead and release an update later today, then I'll look into the display issue after (I'm thinking there was likely always an issue in this area)

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

FrankB

Hi Phil,

After a good nights sleep I think: That's just what -L is supposed to do. Use codepage 1252. And my active codepage is 437. So ignore my remark.
Notes:
- ExifToolGui, as a Windows GUI program, doesn't use a codepage, it always uses UTF8. hence my initial confusion.
- GeoSetter comes with a .exiftool_config. Haven't looked in to it, but I would imagine that it's possible to set 'API WindowsLongPath=0' in that config. And use that as workaround.
- I noticed that meanwhile 13.08 has been released and that fixes it.

Output from a CMD prompt:

C:\temp>chcp
Active code page: 437

C:\temp>dir *.jpg
 Volume in drive C has no label.
 Volume Serial Number is 36C8-B898

 Directory of C:\temp

09-12-2024  13:34         6.980.328 Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Meløyfjord mit Inseln Meløya und Bolga 2024-08-13_1078.jpg
               1 File(s)      6.980.328 bytes
               0 Dir(s)  120.555.606.016 bytes free

C:\temp>exiftool -L -filename *.jpg
File Name                       : Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Mel°yfjord mit Inseln Mel°ya und Bolga 2024-08-13_1078.jpg

C:\temp>chcp 1252
Active code page: 1252

C:\temp>exiftool -L -filename *.jpg
File Name                       : Neverdal, Selstad, Hurtigruten Seereise -  Glomfjord und Meløyfjord mit Inseln Meløya und Bolga 2024-08-13_1078.jpg

C:\temp>

StarGeek

Quote from: FrankB on December 15, 2024, 04:36:05 AMGeoSetter comes with a .exiftool_config. Haven't looked in to it, but I would imagine that it's possible to set 'API WindowsLongPath=0' in that config. And use that as workaround.

Yes, it should be.

I was recently looking at that and was thinking to post it to the forum to keep it available should the GeoSetter website disappear completely. Turns out it has already been posted in this post. Nothing much to it, just a new XMP name space for a tag called ForeignKeys, which I never saw GeoSetter actually write.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype