Xbox-winfsp can't handle weird character

[Landcross]

So, I just ran into the following issue: This OG Xbox disc iso that I'm opening with xbox-winfsp apparently has a filename with a question mark. I don't know why, I don't know how, but it's there and on Windows this file is now totally inaccessible. It still shows up just fine in explorer though:

Would it be possible for xbox-winfsp to (optionally) swap or remove these characters from the filenames to make them accessible? I don't know if it's easy, or even possible at all. If it's a lot of work I doubt it's worth the effort; I don't think there are many cases like this. Nevertheless, something to think about at least haha.

[Landcross]

Ok, I've edited the title because I have some more information. Seems to be a more concrete issue now. Someone suggested checking with extract-xiso and it indeed shows something else than a question mark.

Using extract-xiso in list mode shows it as Gigi R³f.res and using extract-xiso in extract mode extracts it as Gigi Rüf.res

I don't know which one it's supposed to be, but nevertheless both options are better than what xbox-winfsp creates because the file is actually accessible.

[Landcross]

Ok, it's actually supposed to be the umlaut and not a superscript 3: it's someone's name haha https://en.wikipedia.org/wiki/Gigi_R%C3%BCf

[emoose]

Huh, I guess xbox-winfsp doesn't read it in proper encoding, I'd guess it's probaby meant to be UTF-8 or UCS-2 or something, but xb-winfsp always uses ASCII (https://github.com/emoose/xbox-winfsp/blob/master/GdfxFileSystem.cs#L250)

Which game did this happen with? Maybe I can try testing it on my side to figure what encoding it's meant to be.

[Landcross]

The game is "Amped: Freestyle Snowboarding"

[emoose]

Seems it's not UTF8 or UCS-2, but actually ANSI / Extended ASCII, looks like I can use that in C# via Encoding.GetEncoding(1252), which uses the "Windows-1252" character set.

I'm not 100% sure if that's correct encoding though, there's also "ISO-8859-1" which is also known as ANSI, with some differences between them, but both encode the ü the same way. I guess we'll find out if any other strange filenames come up.

For now I've pushed the 1252 change, let me know if that helps for you (should be an updated build artifact at top-right of https://github.com/emoose/xbox-winfsp/runs/3365649547), if so I'll probably make a new release soon, many thanks for reporting it too btw!

[Landcross]

The new version (downloaded from the artifacts) completely breaks down here. Doesn't do anything. Even simply calling the exe without any parameters crashes. Previous versions showed a help message with the various commands.

System.TypeInitializationException: De type-initialisatiefunctie voor Fsp.Interop.Api heeft een uitzondering veroorzaakt. ---> System.EntryPointNotFoundException: cannot get entry point FspFileSystemNotifyBegin
   bij Fsp.Interop.Api.GetEntryPointPtr(IntPtr Module, String Name)
   bij Fsp.Interop.Api.GetEntryPoint[T](IntPtr Module)
   bij Fsp.Interop.Api.LoadProto(IntPtr Module)
   bij Fsp.Interop.Api..cctor()
   --- Einde van intern uitzonderingsstackpad ---
   bij Fsp.Service..ctor(String ServiceName)
   bij XboxWinFsp.Program.Main(String[] args)

[Landcross]

Ok, I took a look at your commit and the above error did not make sense at all based on the minimal changes haha. Apparantly the winfsp-msil.dll bundled with the artifact release causes trouble. Using the .dll from 0.4 works fine.

I can confirm (with the older .dll) it seems to work fine. At least with this specific game. It shows the ü correctly now. If I run in to any other issues I'll let you know of course. Thanks! 👍

[emoose]

Oops meant to reply to this sooner - maybe updating your WinFSP install might have fixed it too, it works fine with 1.10.21164 for me at least.

I don't really want to force people to update though, kinda sucks that the DLL isn't backwards-compatible, guess I'll probably revert that back when I make next release.

Again thanks for letting me know!