search

libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.3k stars 1.84k forks source link

"Filter unknown extensions" not honored inside archives #17148

Open cathoderaydude opened 4 days ago

cathoderaydude commented 4 days ago

Description

The "Filter unknown extensions" setting is only honored in ordinary directories, not inside archives.

Expected behavior

When opening a zip file containing a file that is not compatible with any installed core, if "Filter unknown extensions" is off, I expect the file to be visible.

Actual behavior

The file is not visible, usually resulting in a zip that appears empty.

Steps to reproduce the bug

  1. Disable "Filter unknown extensions"
  2. Create a file with a ".a26" extension
  3. Place the file in a normal directory, and also inside a ZIP
  4. Ensure you do not have an Atari 2600 core installed
  5. Using "Load Content", navigate to the directory on disk
  6. The file appears
  7. Now navigate to the ZIP file
  8. The file does not appear
  9. Install the "Stella" core and repeat above steps
  10. The file is now visible in both the directory and ZIP

Bisect Results

I'm afraid I don't know how to use bisect.

Version/Commit

Environment information

Fix

This seems to be due to a missing check in menu_displaylist.c. I've added checks against filter_exts during calls to the filearchive methods, and in local tests it appears to fix the issue. I will submit and link a PR momentarily.

cathoderaydude commented 2 days ago

I've just realized my PR had an unintended effect, but I'm not sure it's a bad one.

I changed code in two places, not realizing the first one - under _"filebrowser_type == FILEBROWSER_SELECT_FILESUBSYSTEM" - applies when "Filter by current core" is enabled. With my changes, that setting is now overridden by "Filter unknown extensions." So we have the following behavior:

I feel this is desirable, because I don't think anyone would set "Filter unknown extensions = Off" unless they were doing diagnostics of some kind: checking if RA is able to read a given folder at all, trying to feed a file to a core that isn't listed in the compatible extensions, or something similarly unusual. I think anyone in that situation would want this to be a brute-force, "show me everything, no matter what" setting that overrides any related convenience features.

So IMO, this new behavior is probably what most people would want. If there's no disagreement on that point then the change can stand, otherwise you'd just have to revert the first line and leave the second. Ty!