Unable to load rom with # / HASH in the filename

[joolswills]

eg with gpsp

RetroArch [INFO] :: Version: 1.2.2
RetroArch [INFO] :: Git: 27d345c
RetroArch [INFO] :: =================================================
RetroArch [INFO] :: [CPUID]: Features:
RetroArch [INFO] :: Appending config "/tmp/retroarch.cfg"
RetroArch [INFO] :: Loading config from: /opt/retropie/configs/gba/retroarch.cfg.
RetroArch [INFO] :: Loading dynamic libretro core from: "/opt/retropie/libretrocores/lr-gpsp/gpsp_libretro.so"
RetroArch [INFO] :: Environ GET_LOG_INTERFACE.
RetroArch [INFO] :: Environ GET_PERF_INTERFACE.
RetroArch [INFO] :: Environ SET_VARIABLES.
RetroArch [INFO] :: Version of libretro API: 1
RetroArch [INFO] :: Compiled against API: 1
RetroArch [INFO] :: Content loading skipped. Implementation will load it on its own.
RetroArch [INFO] :: Compressed file in case of need_fullpath.Now extracting to temporary directory.
RetroArch [WARN] :: Tried extracting to extraction directory, but extraction directory was not set or found. Setting extraction directory to directory derived by basename...
RetroArch [ERROR] :: Could not read content file "/home/pi/RetroPie/roms/gba/test #.gba".
RetroArch [INFO] :: Skipping SRAM load..

renaming it makes it work fine.

Testing on Raspberry Pi running on linux.

[joolswills]

Full log - http://pastebin.com/cviHxA0U

Eventually segfaults, but all related to being unable to load the file (I guess the libretro core lacks some errors checking too)

[joolswills]

I believe this could be a core specific issue - I just noticed "Content loading skipped. Implementation will load it on its own" - Please can you confirm that and I'll create a new ticket for the emulator(s) that this affects.

[Tatsuya79]

I confirm the # sign causes issues with retroarch. (here on win7 x64)
Any sign before it in the rom name get truncated.

It causes various cores to crash, I tested Nestopia and Genesis+ GX.
It's a sign used in No-Intro sets naming, got some in the Famicom disk system set.

It's a problem in the zip name but not in the rom contained in it.
Uncompressed rom is not launching though.

[DasBiest]

It is also the case for directories in Win 10.The directory will show up in the browser, but if you open it, it throws the message "The directory does not exist"

[fr500]

is used to identify archives (7z) in the current implementation, I guess it needs to be changed

[Alcaro]

Obvious follow up question: Why would such weird characters be used at all in filenames?

Either way, we need to use something for identifying archives, we can't just drop the feature. If not #, then something else.

My suggestion: Use one of the characters banned on Windows, \ / : * ? " < > | since they're banned on the most popular platform, and therefore unlikely to be used on any other platform either.

\ / : are used for file paths, and would make the parser annoying. * ? " look stupid. < suggests the filename is inside the sub-name. > or | would work. I'd say > is slightly prettier.

Alternatively, we could use some multi-character token, for example ".zip#"/etc. But switching to > is easier.

[joolswills]

checking on my fileserver, files containing # = 18129, files containing > = 0

so sounds good to me.

[aliaspider]

invalid chars wouldn't work since the token is used for saves/states filenames.

if you happen to not need compressed archives loading at all, a possible workaround would be compile retroarch without HAVE_COMPRESSION defined.

[v-fox]

RA's homepage says: "Unlike many other programs, Linux is not treated as second-class citizen but as first-class citizen". Well, the only "invalid" Linux character is '/', also "popularity" argument in itself contradicts that statement. Moreover '#' is used in romsets, my Sega MegaDrive folder is full of them. All while there is the issue #2033 where RA skips roms that "violate" romset rules... while actually violating romset rules here. There is also #1746 which is the same for folders.

If you have problems with filenames, it means that you use hacks to treat them or needlessly and erroneously evaluating them. Don't do that. There is no "special" characters beyond '/', even Windows' NTFS actually supports all the characters that crash explorer.exe and are "banned" only in it.

I just heard about RetroArch, made and published fresh rpm-package for it (thank RMS, there is an online updater because without it and without having all necessary stuff in-source-tree it would've been a hell !) in hopes to replace mednafen with something with some kind of a GUI. And right of the bat stumbled upon not one but 3 unfathomable filesystem-related bugs (this is one of them) that prevented me from loading rom-files to it. Not a good first impression at all.

[twinaphex]

The HAVE_COMPRESSION pull request was something made by an external contributor, I will be the first to admit it wasn't really well thought out. I am still intending to kill it eventually and replace it with something better.

Regarding your problems with XFS, debug libretro-common/file/retro_stat.c and/or libretro-common/streams/file_stream.c, the problem likely stems from there. I don't have an XFS-based filesystem so I cannot debug the issue, all my partitions are ext4.

Also, I don't think coming across with an argumentative and hostile approach necessarily gives us a good impression of you as well. Open source software lives and dies by contributions. This is not a one way street. I don't use an XFS filesystem and I was not aware of any issues there. I'm sorry things are not up to your expectations, but I'm sure if you cared and if you had anything to contribute you could do something about it. So I'll allow myself to be pleasantly surprised then, I have little need for bench programmers, I prefer real code contributions.

[fr500]

@v-fox there is no need to set precedent and bring hostility.

Unfathomable...
Caring about Linux doesn't really mean catering to every obscure use case there is.
I agree with the issues about symlinks and fuse filesystems, and even this one. But none of use has felt the need to use XFS.

So yeah, ok there are issues. They will be deal with when we can.

I have a pretty obscure use case in windows, I mount my seafile as a webdav share, and it doesn't really allow loading games either but I understand it's an obscure use case and I wouldn't pretend to make RA adapt to it.

[twinaphex]

I am fine with making the libretro-common code as adaptable as possible to every file system under the sun, it just takes more than a handful of devs to be able to cater to it all, and of course complaining about things is easier than contributing, so it's kinda a catch 22 since I am not exactly well equipped to having a bunch of different system configurations with divergent file systems.

If anybody cares about helping us out with this debugging effort, the offending files are probably limited to the following libretro-common files:

libretro-common/file/retro_dirent.c
libretro-common/file/retro_stat.c
libretro-common/streams/file_stream.c

[bparker06]

this was fixed in #3273