New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to load rom with # / HASH in the filename #2038

Closed
joolswills opened this Issue Aug 13, 2015 · 13 comments

Comments

Projects
None yet
9 participants
@joolswills
Contributor

joolswills commented Aug 13, 2015

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

This comment has been minimized.

Contributor

joolswills commented Aug 13, 2015

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

This comment has been minimized.

Contributor

joolswills commented Aug 13, 2015

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

This comment has been minimized.

Contributor

Tatsuya79 commented Aug 23, 2015

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.

@fr500 fr500 added the bug: minor label Aug 30, 2015

@DasBiest

This comment has been minimized.

DasBiest commented Jan 12, 2016

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

This comment has been minimized.

Contributor

fr500 commented Jan 12, 2016

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

@Alcaro

This comment has been minimized.

Contributor

Alcaro commented Jan 12, 2016

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

This comment has been minimized.

Contributor

joolswills commented Jan 12, 2016

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

so sounds good to me.

@aliaspider

This comment has been minimized.

Contributor

aliaspider commented Jan 12, 2016

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

This comment has been minimized.

v-fox commented May 21, 2016

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

This comment has been minimized.

Member

twinaphex commented May 21, 2016

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

This comment has been minimized.

Contributor

fr500 commented May 21, 2016

@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

This comment has been minimized.

Member

twinaphex commented May 21, 2016

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 comment has been minimized.

Member

bparker06 commented Aug 29, 2016

this was fixed in #3273

@Alcaro Alcaro closed this Aug 29, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment