Internal file name representation

[jbl007]

I'm working on a program for extracting Amiga lha files on the PeeCee side with correct metadata and file names by using _UAEFSDB.___ and .uaem files. It works fine already for filenotes an protection bits, but I have problems understanding how WinUAE handles file names internally.

I'll try to explain with a test case:
Extract the attached zip file to a non-NTFS partition, mount "chartest" as a hard drive and boot from it, close emulator, fsdb file will be created.
If I now take a look at the anames in the _UAEFSDB.___ I expect "clean" byte sequences in the file names: 0xf0-0xff, 0xe0-0xef etc. Works as expected for for 0xc0-0xff but here are the head scratching parts:

For the 0xb0 sequence:
\B0\B1\B2\B3\8E\B5\B6\B7\9E\B9\BA\BB\8C\9C\9F\BF <- got that
\B0\B1\B2\B3\B4\B5\B6\B7\B8\B9\BA\BB\BC\BD\BE\BF <- expected

For the 0xa0 sequence:
\A1\A2\A3\80\A5\8A\A7\9A\A9\AA\AB\AC\AD\AE\AF <- got that
\A1\A2\A3\A4\A5\A6\A7\A8\A9\AA\AB\AC\AD\AE\AF <- expected

Questions are now:
1. Am I missing something? Is my test case wrong?
2. Is this a WinUAE bug? (It seems so, because it works as expected with Amiberry.)
3. If not, why is it done this way and
4. what is the logic behind it?

BTW: Not only the names in the db are wrong, WinUAE also dumps wrong bytes as file names to the host file system (Linux/wine). :-\
So the problem is not actually fsdb related, it's only showing up there.

[thomas]

It's probably the difference between ISO-8859-1 and Windows-1252 code pages.

[jbl007]

Originally Posted by thomas

It's probably the difference between ISO-8859-1 and Windows-1252 code pages.

You're on the right track. Looks more like a ISO-8859-15 to cp1252 conversion:
https://de.wikipedia.org/wiki/Windows-1252 (bottom of the page).
But why do conversion for the INTERNAL file names? Bytes should stay bytes as they are...

[Toni Wilen]

It looks like it is translated name which (as you said) shouldn't be stored. It probably got broken ages ago or something and no one has noticed because it does not normally cause any "visible" side-effects.

[jbl007]

So basically a design decision from the good old Windows XP days from when cp1252 was a thing, maybe ever earlier. Nice code artifact.

I wonder if it always worked that way or it got broken on the long road from back then.


I assume, you will not fix it, because it will break compatibility!?