-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
RetroArch saves the real path of a symbolic link to playlist files #9163
Comments
@jdgleaver Maybe you would like to look at this one? |
Ah, okay - the reason for switching over to using resolved symlink paths in playlists was that users were complaining about duplicate entries (e.g. if you load content via the 'real' path, and subsequently load it via the symlinked path, you get a duplicate in content history) I guess we may have been overzealous - we need to check the resolved path when searching/pushing content, but we can probably save the 'input' path without issue. There's currently this PR awaiting approval: #9137. This makes some changes to |
Thank you. |
Bump. Any updates? |
Just ran into this bug as well. I'm trying to replicate and synchronise my retroarch setup on multiple systems, and symlinks are vital for me. Hard links are horrible so my workaround is currently to just sed the playlist files to restore the correct path to the symlink. |
This is what portable playlists are for.
And you get playlist transparency for free (as long as you don't use the same config file for different platforms of course, which is already impossible for other reasons unless your system has the exact same paths anyway). If you want a 'completely portable' RetroArch this can be done by having 2 directories in a pen drive, one with (for example), the windows executable and windows retroarch.cfg, the other with the Linux executable and retroarch.cfg. Or if you prefer a single dir, a sh\bat file to use different cfg files for each executable. I find portable installs of RA unnecessary though, if you can install it on both systems. Portable playlists work by fixing up paths in playlists if the playlist base_content_directory (added to playlists if you have file browser path set and portable playlists on) doesn't equal the current file browser path setting. If it doesn't, it replaces, all the parts of the entries paths that start with it by the new one, and in windows replaces / by \ and vice versa for from windows to unix - note this has no problems with dumping groups games filenames because they forbid \ and / in filenames. |
Here is how it looks, parts with double asterisks are the parts replaced (not counting the slashes)
The core path also has a fallback, although I didn't really understand the code to explain it. |
Symlinks are still resolved to their real paths in the playlists. How can we disable this and let playlist point to the symlink path??? |
RetroArch solution to this is portable playlists, because symlinks, frankly, will give you a false sense of security without a lot more scripting than you probably expect. This is because, in general, the config file (retroarch.cfg), that holds the paths to most files, cant be shared across systems (there are hidden random paths for things like downloaded asset zip files, os and system dependent settings) and in the case of paths only inside the the playlists, symlinks switches will only work in the same type of OS, with the same path seperators and drive names. The playlist can also only hold absolute paths (because different platforms have different relative locations for the current directory), but thats different than canonical paths (symlinks eliminated) so it's irrelevant to that decision. In short, it doesn't work, probably by accident, but if it did work and you ran a script before running RetroArch to switch locations... It would still be doing it wrong. Probably as soon as you wanted to run the same games drive in windows and linux\mac\openbsd. Or your path to the games directory required the current username on it and you needed a sudo on your symlink switch script in a system with another username you're using... The portable playlists transformation also has a limitation it can't avoid. Directories names can't have either \ or / in the playlist paths. But that's easy, since redump\nointro\windows already avoids that afaik. |
Description
When RetroArch opens a symbolic link as content using the file browser, it loads any directory or content specific configuration files, resolves the path to the real file and then opens it. This works as expected.
The problem is RetroArch saves the resolved path to the playlist files. When the same content is opened via history, favorites or any other playlist, the directory and content specific configuration files may not be loaded because the real directory and file names may not match the ones the user loaded and configured via the file browser.
Expected behavior
Actual behavior
Steps to reproduce the bug
prefix=~/retroarch-symlink-test
mkdir -p $prefix/symbolic $prefix/real
$prefix/real/content
ln -s $prefix/real/content $prefix/symbolic/game
$prefix/symbolic/game
in the file browsersymbolic.rmp
$prefix/real/content
was saved to thecontent_favorites.lpl
playlist filesymbolic.rmp
has not been applied$prefix/symbolic/game
in the file browsersymbolic.rmp
has been appliedSince
$prefix/real/content
was saved to the playlist, RetroArch looks for a content directory remap file namedreal.rmp
instead ofsymbolic.rmp
. When the symbolic link is loaded from the file browser, RetroArch loadssymbolic.rmp
as expected.Workarounds
Use hard links instead of symbolic links.
Version/Commit
Environment information
The text was updated successfully, but these errors were encountered: