retro rewind starts with this screen using flatpak

[soccerboys2008]

this doesn't happen when i built from source (version 2407-39), but does happen on the flatpak (version 2407)

not sure if this was fixed by dolphin in between these versions, or if its a flatpak issue

[soccerboys2008]

Seems to be a permissions / sandbox issue, Link: https://github.com/patchzyy/WheelWizard/issues/3#issuecomment-2223133856

[cpba]

This should be easy to test.

@soccerboys2008 please test this build here, it's 2407-39 so we'll be able to rule it out.

Also try running the flatpak with full filesystem access with something like this: flatpak run --filesystem=host org.DolphinEmu.dolphin-emu

This way we can also rule out filesystem access.

How does this mod work, does it need outside binaries?

[soccerboys2008]

um, this was the test build

[soccerboys2008]

How does this mod work, does it need outside binaries?

I'm not entirely sure if the mod is supposed to be writing to the dolphin load folder, but i can ask the dev and see if i get a response

EDIT: at least i believe its trying to write to the directory, because other riivolution mods don't have this issue

[soccerboys2008]

Also try running the flatpak with full filesystem access with something like this: flatpak run --filesystem=host org.DolphinEmu.dolphin-emu

this works

[soccerboys2008]

here is the riivolution xml for retrorewind6 if it helps: https://drive.google.com/file/d/1ihKeE4Ne1BMIMmiS9Z8q1oY0e7ajs4fY/view?usp=sharing

[soccerboys2008]

ok, i decided to give the test build another shot to see if that error was caused by the files being created by the dolphin i built from src

but i couldn't reproduce it (maybe the src builds process got hung on it even after emulation stopped idk)

point being i can't reproduce it

but the test build does work

[cpba]

ok, i decided to give the test build another shot to see if that error was caused by the files being created by the dolphin i built from src

but i couldn't reproduce it (maybe the src builds process got hung on it even after emulation stopped idk)

point being i can't reproduce it

but the test build does work

No need to bother with it any longer, I made the test build merely to rule out an upstream regression, which you have already done.

Also try running the flatpak with full filesystem access with something like this: flatpak run --filesystem=host org.DolphinEmu.dolphin-emu

this works

Well, that should explain it then. This mod you're trying to use attempts to write to some directory outside the dolphin configuration directory, this is outside the sandbox so it fails.

@soccerboys2008 If you can figure out the exact directory it needs to write to we could try adding in a workaround, or at least a note in the readme explaining what to do to make it work.

The option --filesystem=host grants access to almost the entire filesystem, you should change it to whichever specific directory you need.

[soccerboys2008]

@soccerboys2008 If you can figure out the exact directory it needs to write to we could try adding in a workaround, or at least a note in the readme explaining what to do to make it work.

The option --filesystem=host grants access to almost the entire filesystem, you should change it to whichever specific directory you need.

i had the riivolution folder set to the location where i keep my game dumps, and wii mod downloads (an organization thing), and so i had easy access to it since dolphin allowed me to set the directory

as for what i was trying to do, load the mod, and play it (this has never happened before with other riivolution mods, this is the first one that i seen that keeps savedata in the dolphin loads folder, saw it in the xml file i sent, after i followed the path given from the test build)

[soccerboys2008]

the only workaround i can think of in this situation is whenever a mod tries to write data to a directory outside sandbox, it gets rerouted to inside the sandbox (maybe have a directory structure that is the same as the absolute path of the dolphin loads folder (if changed from default) inside the sandbox, that can be written to by the mod

also means it would need to be read, kinda reminds me of the overlayfs stuff happening with immutable distros, we take the files that the mod wrote, and overlay it over top the of the files at the read only location

EDIT: the other option is disabling the ability to change the location of the dolphin loads folder

[cpba]

the only workaround i can think of in this situation is whenever a mod tries to write data to a directory outside sandbox, it gets rerouted to inside the sandbox (maybe have a directory structure that is the same as the absolute path of the dolphin loads folder (if changed from default) inside the sandbox, that can be written to by the mod

also means it would need to be read, kinda reminds me of the overlayfs stuff happening with immutable distros, we take the files that the mod wrote, and overlay it over top the of the files at the read only location

EDIT: the other option is disabling the ability to change the location of the dolphin loads folder

Theres an option called --persist that can be used to map specific directories into the sandbox, however, from what you're telling me it looks like the specific directory is chosen by the user so it wouldn't help.

I feel like the portal should be able to deal with this in some way, it might be worth looking into the specifics of why it isn't.

The best I can do about it is to add a note to the readme explaining that some mod might need write access and how to provide it.

[ColinKinloch]

Would adding ~/Wii to the filesystem overwrites in flatseal not fix this?

[soccerboys2008]

That was a user specified directory so no

The user (me in this case) set the dolphin load folder location to a directory within $HOME/Wii

If someone wanted they could set the location of the dolphin load folder to $HOME/hdkfy and break it

The issue is a combination of user choice, and the sandbox

[ColinKinloch]

Oh, I see, you're trying to come up with a general solution.

So the riivolution patch sets up directories relative to the XML file, is that right? Portals aren't currently able to do this sort of thing (read write for parent dir of selected file).

I think the most flatpak correct way to achieve what you're wanting is to set the permission overwrite in flatseal. The alternative is home permission but if the files are in external drives it would be hostwhich is basically just switching off the sandbox, which I'm against.

[soccerboys2008]

The riivolution patch for some reason writes save data to the riivolution folder under Dolphin load folder/Riivolution/riivolution

The save location can be changed via the XML (provided above)

But a normal user wouldn't edit an xml to change the save location

And a normal mod doesn't put save data in the dolphin loads folder, other riivolution mods I've used don't have this problem (prob cause they just read what they need, and put the save data in dolphin nand (or whatever you call it))

TLDR: so yes your right, looking for general solution

[ColinKinloch]

Yes, and unfortunately the user experience for flatpaks sometimes involve overwriting the default filesystem permissions with specific directories.

I think that this issue is best solved in dolphin or xdg-portals and not this package.

[soccerboys2008]

The issue is building from source has no issues, and that's because when building from source it's not bound by flatpaks permissions and sandbox

So the source build can write to those directories no questions asked

Making this a flatpak problem not a dolphin one (since the flatpak is unofficial, the only official channel for dolphin on Linux unfortunately is building from source)

[soccerboys2008]

However is dolphin went and made the flatpak an official distribution, then it would be a dolphin problem

(Really hope one day this becomes official)