Steamdeck with Emudeck: Some changes below $SDCard/Emulation/saves/ are not picked up
hkramski opened this issue · comments
Ludusavi version
v0.22.0
Operating system
Linux (Steam Deck)
Installation method
Flatpak
Description
I'm using a standard Emudeck installation on SD Card on a Steam Deck and Ludusavi 0.22.0 (Flatpak).
I have defined a custom game "Emulations-saves" with a path on my SD card: /run/media/deck/c2xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxe8/Emulation/saves
.
Turns out Ludusavi picks up changes e.g. below /run/media/deck/c2xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxe8/Emulation/saves/yuzu/saves/
(which is a symbolic link to /run/media/deck/c2xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxe8/Emulation/storage/yuzu/nand/user/save/
) but not below e.g. /run/media/deck/c2xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxe8/Emulation/saves/dolphin/Wii
(which is a symbolic link to /home/deck/.var/app/org.DolphinEmu.dolphin-emu/data/dolphin-emu/Wii
). (These symbolic links were made by the Emudeck installer.)
To fix this, I granted r/w access to /home/deck/.var/app
in KDE Plasma's system setup module for flatpak applications.
I am not sure whether the management of these access rights is the responsibility of the user or the Ludusavi flatpak installer. I am reporting it here in case it is an installer.
In a typical Emudeck installation, there are numerous folders for emulators in /home/deck/.var/app/
that may be relevant to savegames.
Logs
[2023-12-30T13:43:08.999Z] WARN [ludusavi::prelude] failed to walk: Some("/run/media/deck/c2xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxe8/Emulation/saves/dolphin/Wii") | Error { depth: 2, inner: Io { path: Some("/run/media/deck/c2c2xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxe8/Emulation/saves/dolphin/Wii"), err: Os { code: 2, kind: NotFound, message: "No such file or directory" } } }
I am not sure whether the management of these access rights is the responsibility of the user or the Ludusavi flatpak installer.
I think the Flatpak team generally wants app developers to keep their default permissions pretty limited, but I also agree that having access to ~/.var/app
makes sense here since it's a common enough use case. I've updated the default permissions to include it :)