[libretro] saving/loading broken when savefiles_in_content_dir = "true"

[bsdf]

Game or games this happens in

None

What area of the game / PPSSPP

when the retroarch option savefiles_in_content_dir is set to "true", the system/save directories are created next to the rom file but PPSSPP attempts to access them as a subfolder of PSP. to illustrate:

after loading ~/roms/psp/game.iso:

# ls ~/roms/psp/
game.iso
PPSSPP_STATE/
SAVEDATA/
SYSTEM/

however, when attempting to save, the following error is received:

[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/SAVEDATA/NPUH10031ANIKI/PARAM.SFO'): FAILED, 2 - access = 1 ''

What should happen

the system/save data should be created in a PSP folder next to the content:

# find ~/roms/psp/
game.iso
PSP/PPSSPP_STATE/
PSP/SAVEDATA/
PSP/SYSTEM/
...

or PPSSPP should look for these dirs without the PSP parent folder

Logs

[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/SAVEDATA/NPUH10031ANIKI/PARAM.SFO'): FAILED, 2 - access = 1 ''
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/SAVEDATA/NPUH10031ANIKI/PARAM.SFO'): FAILED, 2 - access = 26 ''
[libretro ERROR] [FILESYS] DirectoryFileSystem::OpenFile('/PSP/SAVEDATA/NPUH10031ANIKI/DATA.DAT'): FAILED, 2 - access = 26 ''
[libretro ERROR] [SCEUTIL] Error writing file ms0:/PSP/SAVEDATA/NPUH10031ANIKI/DATA.DAT

Platform

Linux / BSD

Mobile phone model or graphics card

n/a

PPSSPP version affected

PPSSPP (version 1120003)

Last working version

No response

Graphics backend (3D API)

Vulkan

Checklist

• Test in the latest git build in case it's already fixed.
• Search for other reports of the same issue.
• Try resetting settings or older versions and include if the issue is related.
• Try without any cheats and without loading any save states.
• Include logs or screenshots of issue.

[unknownbrackets]

Games hardcode the path /PSP/SAVEDATA inside their code. The option isn't really a smart idea to begin with for PSP games.

-[Unknown]

[AnalogMan151]

I am also experiencing this issue on Steam Deck. If your content directory is on the MicroSD then when savefiles_in_content_dir = "true" is set, the reported behavior occurs. However, I tried setting savefiles_in_content_dir = "false" and then overriding the save directory to be the content directory on MicroSD and it still showed the same behavior. If saves are left to their default directory within RetroArch everything saves and works fine.

[bslenul]

Just messed with this a bit, looks like this bug happens when the folder where the games are stored is named "PSP".

For example:

• ~/Games/Sony - PlayStation Portable/game.iso will work properly and ~/Games/Sony - PlayStation Portable/PSP/ will be created with "SAVEDATA" and other folders inside.
• ~/Games/PSP/game.iso however will NOT create ~/Games/PSP/PSP/ and the "SAVEDATA" folder will be created directly in ~/Games/PSP/.

This seems to be a PPSSPP issue as it happens on standalone as well, easy to reproduce:

1. Create a PSP folder somewhere.
2. Point to that folder with the "Save path in installed.txt" option.
3. Launch a game and you'll see the "SAVEDATA" folder (and a few others) being created directly in that "PSP" folder.
4. Now repeat the above with a TEST folder or whatever, and you'll see the "SAVEDATA" folder being created correctly in TEST/PSP/.

I say "issue" but idk, maybe this is done on purpose for some reason?

[LunaMoo]

@bslenul Not exactly what's reported in this issue. The problem here is libretro enforces memstick path in some awful way and PPSSPP doesn't see it's savedata, with the steps you "reproduced" the problem on proper PPSSPP - savedata is read correctly, so it's not really an issue in real PPSSPP.

"PSP" folder behavior is expected, but doesn't seem related to the above following first post explaining the issue, having PSP/PSP would be weird and ugly and on mobiles which have physical "memstick" we start memstick directory from PSP.

[bslenul]

Not exactly what's reported in this issue.

Yeah sorry, just trying to figure why it's happening :p And I was curious to know if it was a bug or if it was intended.

edit: Ah, I should've searched a bit first, my answer was here:

ppsspp/Core/System.cpp

Lines 622 to 627 in 35dfd85

	if (!strcasecmp(memStickDirectory.GetFilename().c_str(), "PSP")) {
	// Let's strip this off, to easily allow choosing a root directory named "PSP" on Android.
	pspDirectory = memStickDirectory;
	} else {
	pspDirectory = memStickDirectory / "PSP";
	}

Sorry about that.

Weirdly enough, the RetroArch issue doesn't happen on Windows, the save is read properly even if the "SAVEDATA" folder is created inside the game folder 🤔 I'm able to reproduce the issue on my Linux Mint VM however.

[pressRtowin]

Yep, still having this issue. I'm on Android 13.

[bsdf]

Just messed with this a bit, looks like this bug happens when the folder where the games are stored is named "PSP".

good catch-- and indeed it looks like that might have been the cause of my original issue. i had edited the pathnames in my original report to anonymize and didn't even realize that the pathname might have had relevant information.

i've gone ahead and updated the examples to more accurately reflect the actual folder structure

[bsdf]

"PSP" folder behavior is expected, but doesn't seem related to the above following first post explaining the issue, having PSP/PSP would be weird and ugly and on mobiles which have physical "memstick" we start memstick directory from PSP.

given @bslenul's investigation, it's looking like this issue is leaning towards "working as intended" territory. though before it's closed out, i think it's worth having a discussion on whether or not it makes sense from a libretro perspective with the savefiles_in_content_dir=true setting. i don't 100% understand the Android use-case so please forgive me, i'm only speaking from a desktop+libretro perspective

from what i understand, savefiles_in_content_dir means store the save data in the same directory as the loaded rom file. since the /PSP/root dir is hardcoded in games, i would consider the PSP dir as a necessary part of the save data. given that, if i load $ROM_DIR/rom.iso, i would expect the folder $ROM_DIR/PSP/ to be created, regardless of what the parent dir of the rom is named. in the case where ROM_DIR=~/roms/psp, i would expect ~/roms/psp/PSP to be created

while ~/psp/PSP, ~/PSP/PSP, ~/pSp/PSP etc might be weird and ugly, i think it is the expected behavior given savefiles_in_content_dir

[pressRtowin]

Oh, I actually misread this, but I suspect it's something similar. I don't use the savefiles_in_content_dir option, but instead I'm using the option to sort saves by content directory, and my ROMs are in a directory named "PSP" as well. So my saves are in a /PSP subdirectory within the default libretro saves directory.

[tydaze]

I ran into an opposite issue using RetroArch 1.15.0 on Windows 10 when using a relative path (".\saves") for the "save" directory. With the default RetroArch setting of "Write Saves to Content Directory" option OFF, the PPSSPP core was not able to create any save files. But with "Write Saves to Content Directory" set to ON, saving works normally. It is the only core I have come across so far with this issue.

[npaladin2000]

I"m running into this issue as well on a Retroid Pocket 3+. I sync my saves with a ChimeraOS machine which keeps the savegames in a foler called PSP so I don't have the option of using a seperate folder or using the rom folder.

[SnoFox]

Hi there,

I believe this also causes an issue with specific SteamDeck setups; most notably, mine.

With a directory tree like /run/media/mmcblk0p1/roms/PSP/Patapon.iso and the sort_savefiles_by_content_enable set to true, RetroArch on Steam wants to save to /SteamLibrary/steamapps/common/RetroArch/saves/PSP/SAVEDATA/UCUS98711_DATA01. This succeeds on Windows, but fails on Linux.

In the mean time for me, I've just renamed my PSP directory to PSPortable, which now creates saves at /SteamLibrary/steamapps/common/RetroArch/saves/PSPortable/PSP/SAVEDATA.

I've created a post on Steam Community as well: https://steamcommunity.com/app/1118310/discussions/3/3805030629037194467/