Retroarch: Hide Online Updater Menu Items when folders are not writable

[RobLoach]

When a user's core info directory is not writable, and the user tries to update the info files via "Online Updater" -> "Update Core Info Files", they get an error that looks like the following:

[ERROR] Download of 'info.zip' failed: Write failed.

This occurs on the Flatpak build, since the Flatpak package ships all asset/info files with the package, and updates them periodically when needed, directly through the Flatpak. This issue was originally reported over at https://github.com/flathub/org.libretro.RetroArch/issues/102 .

It would be great to hide Online Updater menu options when the respective folder is not writable. That way, the user wouldn't unnecessarily try to update the info/asset files, and get a error that they don't understand.

TLDR: Hide Online Updater menu options when the user doesn't have write access to the respective folder.

[orbea]

Essentially a duplicate of issue https://github.com/libretro/RetroArch/issues/3237.

Also the Flatpak package should compile RetroArch with ./configure --disable-update_assets if they are providing assets in the package.

[bparker06]

Which respective folder? The updater may write to several differently configured folder locations.

And won't this negatively affect people trying to give support to users who can't find the updater?

Why not just make the updater say that the folder for the requestion action is not writeable instead?

[orbea]

Why not just make the updater say that the folder for the requestion action is not writeable instead?

Yes, I agree with this suggestion.

[RobLoach]

Essentially a duplicate of issue #3237.

Somewhat, yes. Would love to see merging of multiple directories for a lot of these. Mounting multiple directories, and grabbing the last in the list would be great. Does the VFS do this? I know PhysFS allows for it...

Also the Flatpak package should compile RetroArch with ./configure --disable-update_assets if they are providing assets in the package.

Didn't know of --disable-update_assets. Which items does this apply to? Could we add other ones? When using Flatpak, you don't need to update the following in the Online Updater:

• Update Core Info Files
• Update Assets
• Update Joypad Profiles
• Update Cheats
• Update Databases
• Update Cg Shaders
• Update GLSL Shaders
• Update Slang Shaders

Could see something similar apply to the PPA with retroarch-assets, if .info files ever get added to the PPAs.

Why not just make the updater say that the folder for the requestion action is not writeable instead?

A nice check and warning message might be enough. "Directory is not writable, you probably don't need to update this"... or something. It still might confuse some users.

[orbea]

Somewhat, yes. Would love to see merging of multiple directories for a lot of these. Mounting multiple directories, and grabbing the last in the list would be great. Does the VFS do this? I know PhysFS allows for it...

I don't think we need anything so intensive, it just needs to be able to look at more than one directory and distinguish which directory is which and which core/info files belong to which. And then present them in a single list. Look at dolphin-emu for example, they more or less implemented this with content directories where you can easily have different directories for gc and wii games and still access them in a single content list.

Didn't know of --disable-update_assets. Which items does this apply to? Could we add other ones? When using Flatpak, you don't need to update the following in the Online Updater:

For cores and core info files I recommend setting this in /etc/retroarch.cfg and then documenting how to change this.

menu_show_core_updater = false

For example I added this README to the Slackware package.

https://slackbuilds.org/slackbuilds/14.2/games/RetroArch/README.SLACKWARE

The issue I linked would largely make this unnecessary if fixed where package maintainers could provide cores and the user could also use the buildbot cores without any conflict of interest or configuration.

For the others, I'm not sure at the moment and I'd think they would be useful to update by the user even when the package is not updated.