Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
08074 Media Support Major Always Sep 2, 2021, 13:52 Sep 5, 2021, 20:59
Tester vidpro1 View Status Public Platform MAME (Official Binary)
Assigned To cuavas Resolution Fixed OS Windows 10 (64-bit)
Status [?] Resolved Driver
Version 0.235 Fixed in Version 0.236 Build 64-bit
Fixed in Git Commit 4f49599 Github Pull Request #
Summary 08074: FILE MANAGER: Attempted loading of loose software does not work.
Description If you load a console like NES ie mame nes with no game and try to browse a directory like C:\ drive you get an error.
Drive letters get an error if you try to enter them. It wouldn't be limited to just loading a console. It would not allow entering subdirectories by drive letter.

This used to work fine on previous versions.
Steps To Reproduce
Additional Information
Github Commit
Regression Version 0.235
Affected Sets / Systems FILE MANAGER
Attached Files
png file icon directoryerror.png (82,898 bytes) Sep 2, 2021, 13:53 Uploaded by vidpro1
There are no relationship linked to this issue.
User avatar
Senior Tester
Sep 2, 2021, 19:27
This should be a frontend or OSD issue (Windows only?), not NES specific, no?
User avatar
Sep 2, 2021, 19:29
edited on: Sep 2, 2021, 19:31
I'm seeing this too. also same on Genesis

Selecting through SL works fine though.
User avatar
Sep 2, 2021, 19:45
Only chose NES initially since it was the test that was shown and was confirmed. It is very likely the same issue happens with other systems
When I get some time I'll isolate the breaking commit since it appears to be recent.
User avatar
Sep 3, 2021, 01:42
I've done some checking it seems it was broken with a after freeze commit just before 0.235 went out the door for official binary

You can navigate the current drive where mame resides, it appears, but not to the root of that drive or any other drive listed.
Changed from nes specific to at least a Windows specific issue. Unsure if tested on SDL yet.
User avatar
Senior Tester
Sep 3, 2021, 03:25
Confirmed that the last-minute change broke the file manager drive selection. I reverted it locally and the problem went away.
User avatar
Sep 5, 2021, 14:45
The issue is checking for WIN32 as a predefined symbol in C++17 mode. It was predefined in C++14 mode, but no longer is in C++17 mode – code has to use _WIN32 instead. There are several examples of this in src/lib/util.
User avatar
Sep 5, 2021, 20:59
There were multiple issues at play here. After #8443 was applied, is_root was simply never returning true on Windows, as OSD_WINDOWS isn't actually defined outside libosd and libocore. This caused phantom parent items to appear in disk roots on Windows, but it meant that the check in zippath_resolve would always fail so the trailing backslash would be trimmed. Fixing the macro test in is_root meant the trailing backslash from C:\ would no longer be trimmed, which caused the stat in zippath_resolve to fail, preventing the disk root from being browsed. The excess path separators need to be trimmed or the stat fails on Windows.