"Illegal characters in path" from GBC rom being treated as an Archive

[TiKevin83]

The Emperor's New Groove ROM for GBC is treated as an archive causing an exception in the ROMLoader

Repro

Try to load the above rom

Output

[zeromus]

Extensions other than zip,7z,rar,gz,bz2,xz should not be candidates for testing for IsArchiveness
CommonNonArchiveExtensions in HawkFile.cs is WEAK SAUCE. Remove this and replace with AssumedDefiniteArchiveExtensions and a comment that says "files with this extension must be an archive, or the file can't be loaded".

[YoshiRulz]

Current theory is that these roms happen to have the magic numbers of a TAR archive.

---

Also reported on Discord with Kirby's Dream Land 2 (also a GB rom):

[zeromus]

Current theory is you're testing a .gbc extension to see if it's an archive, else you wouldnt get a chance to find a TAR magic number in it

[YoshiRulz]

^ thoughts? (also let me know if the debugger attr works, I grabbed it off SO)

[TiKevin83]

I'm inclined to agree with zeromus that it's not ideal that you'd even need to try to recover from reading a file with a .gb/,gbc extension as an archive in the first place, but perhaps that commit is still useful for cases like the .lsmv where something not expected to be an archive by extension turns out to be one.

[vadosnaprimer]

If we want to support something, we want to be clear about it, to ourselves and others. lsnes is one of the few emulators that uses plain renamed zip, so it's easier to support it explicitly. Implicit support is accidental and relies on luck, and we want to not depend on luck, for us and users.

[nattthebear]

#2589 gets the HawkFile dependency out of lsmv import, so we can stop worrying about that for this.

[YoshiRulz]

Well and truly fixed now. OP's rom, and I assume those from other reports, don't even have the magic bytes of a modern .tar. Instead, SharpCompress was identifying them as the original .tar format (tracked upstream as adamhathcock/sharpcompress#390).

---

I still think 0ba29e7 is a good idea, just not sure if it's the best implementation. I think the ideal is to try incoming files as roms first, then archives (or concurrently, but the precedence should be for roms). Refactoring RomLoader just doesn't sound appealing to me right now.