Hello again.

I've just returned to regular browsing again after a period of absence due to medical reasons, and one of the first things I did (yesterday) was to download the latest snes9x v4.4.8 release. But in testing it I was a bit surprised to note that it still suffers from some major bugs in the file browser, which also makes it hard to correctly configure any of the path options.

Fortunately it is possible to achieve paths that do work, despite being incorrect (which they always become), but you really need to fix this sometime soon, especially as this bug apparently is included in several others of the emulators for the PS3.

There are at least two bugs involved here, the simplest one being an incorrect usage of the leading slash, such that any browsed path string gets an extra '/' character at its start, so that it begins with two leading slashes instead of one. But it is a little more complex than just that, as the main path string displayed in the file browser will get another instance of doubled slashes whenever you browse from the configured ROM path into a subfolder. It is pure luck that the PS3 filesystem was coded to be tolerant of such errors, apparently just ignoring the redundant slash characters, whereas it would really be more correct to refuse access and throw up an error message.

The second bug, giving even more irritating results, might never be seen by those who use a small ROM collection, needing no genre subfolders. That is because this bug involves improper dealing with the case of backing out of a folder, using the ".." entry, which is instead treated as if it was a true subfolder name.

Now since I have a huge collection and therefore use a large number of subfolders, this makes the problem obvious whenever I browse back and forth between them. And any path option configured with such browsing becomes completely insane, as it contains one distinct reference to each subfolder visited for each time it was visited in the current browsing. Like I said above, the paths may still work, but this is more due to luck than anything else.

Some examples:

My main ROM collection for all EMUs is stored in a place independent of any specific emulator, in the folder "/dev_hdd0/GAMES/-_Emu_ROM/" and there I have separate subfolders for each emulated console, including one named "SNES_ROM". So if I simply start the emulator and directly configure it to have that path as the default ROM path, then that will become (erroneously) configured to be "//dev_hdd0/GAMES/-_Emu_ROM/SNES_ROM/", and on future relaunches of the emulator that will be the starting path, which is almost correct (except for the extra leading slash).

However, if I then go into the subfolder named "SNES FPS" (containing FPS ".smc" ROMs) then the path becomes slightly more incorrect as "//dev_hdd0/GAMES/-_Emu_ROM/SNES_ROM//SNES FPS" (note the second slash doubling). This is further aggravated if I change my mind and back out of this subfolder, and then instead enter one named "SNES RPG", after which the total path string will look like this:
"//dev_hdd0/GAMES/-_Emu_ROM/SNES_ROM//SNES FPS/../SNES RPG"

And if I repeat such backing and reselection a few times I can end up with truly insane path strings, like this one (no exaggeration)...:
"//dev_hdd0/GAMES/-_Emu_ROM/SNES_ROM//SNES FPS/../SNES RPG/../SNES Strategy/../SNES Squaresoft/../SNES FPS" (and so on, without known limits)

I will leave it to your imagination what would happen if I were to use this kind of browsing in deciding how to configure the path options, with similar insanity resulting in those strings.

Like I said further above, the extreme tolerance of the PS3 filesystem coding does allow such erroneous paths to work, but that is no valid reason to leave the errors unfixed.

As I see it what needs to be done is simply this:

1: When starting a file browser in the system root and an entry is chosen, do NOT deal with this as you would with a subfolder, first adding a '/' separator to the existing path string and then adding the device name string to that. This is what creates the first doubled slash. There are two easy ways to fix it. Either init the root path string just to NUL instead of "/", or else keep track of folder levels and skip the separator addition at level 0. Either way will eliminate this case of slash doubling.

2: Whenever a configured path is stored, do so consistently with how the internal default path strings are stored, without adding an extra slash at the end of the string. (possibly removing a final slash if added by the browsing code). This will eliminate the other case of slash doubling.

3: Whenever the user browses back out of a folder with the ".." entry, you must recognize this as a special command sequence, not treating it as a true folder name like you currently do. Instead you need to remove the last path segment (up to the preceding '/'), so as to restore the path string to what it was before entering the folder you are now leaving. And this will eliminate all the erroneous "/../old_folder_name" occurrencies.

Though I haven't tested all of them, I assume that these fixes need to be applied to all of the emulators with a file browser related to the one of snes9x...

I hope you receive this in the positive spirit I intended it.
It was not my intention to criticize your work, but merely to point out a spot needing some 'polish'.

Best regards: dlanor