[Mouad-Scriptz-0]

What

sceSaveDataGetMountInfo and sceSaveDataDirNameSearch reported every directory as 32768 blocks with 32768 free. A mount that creates a directory now records the block count it asked for in a .blocks file next to the directory's .param file, and both calls report that count with the free blocks reduced by the directory's files in 32 KiB blocks. sceSaveDataDelete removes the record with the directory. A directory with no record (made before this change, or by hand) reports its files rounded up to the 96-block minimum as its allocation; opening one does not record the opening mount's count, which is not the creation size.

Minecraft (PPSA17221) sums the allocations of its save directories (the search's blocks, taken as 64 KiB each) against a 9 GiB budget and sets its low-storage state when less than 100 MiB is left (full below 10 MiB): five directories at the 32768-block maximum summed to 10 GiB, so it showed "You are almost out of data storage space" and refused to open or create worlds (read out of the title with gdb: used 10 GiB, total 9 GiB, available 0). With the recorded sizes (80 blocks for its settings, 1535 for its level cache) the sum is a few hundred blocks, worlds open and create, and the world list shows a world's real size (1.4 MB where it showed 0.01 MB).

Tested

Fedora 44 (kernel 7.2.8, GCC 16.2.1, Ninja, Release, BUILD_TESTING=ON), worktree on main 5d50886: new guest_savedata_blocks (a created directory reports its requested blocks, free blocks drop with files rounded up to 32 KiB blocks, the search agrees with the mount info, reopening with another count keeps the created size, delete removes the record, opening a directory without a record records nothing); a directory without a record reports its files rounded up to the minimum and grows with them; guest_savedata_search and guest_savedata_delete still pass; tools/check_conventions.py --base origin/main and git diff --check pass. Minecraft: worlds open and create again, and the world list shows a world's real size (1.4 MB where it showed 0.01 MB); the dialog stayed away through a play session. Not tested on Windows.

Checklist

• Follows docs/dev/CONVENTIONS.md
• Tests added or updated
• No new technical debt without an entry
• Unblocks: PPSA17221 (no Game bring-up discussion yet)
• AI-assisted: yes (Claude Code).

🤖 Generated with Claude Code

[johnmaia]

Windows run, since the description says Windows is untested. Setup: Windows 11 (26300), WinLibs GCC 15.2.0 r7, Python 3.12, Git for Windows, Release, BUILD_TESTING=ON, ctest -j4 --timeout 300, RTX 4080. Head e8d947d merged into main 69b4ca5.

• guest_savedata_blocks, guest_savedata_search and guest_savedata_delete pass.
• The full suite passes 1082 of 1082.

Not tested: a negative control on Windows, and a title.

AI-assisted: yes (Claude Code)

[Zenodeon]

Windows validation of the submitted head e8d947d31cfdde0d8e27b4563e2a73a416fdad25:

• Native Windows x86-64 (10.0.26200), WinLibs MinGW-w64 GCC 15.2.0 r7, Ninja Release, Python 3.12.14, BUILD_TESTING=ON, pinned submodules.
• Configured the normal runtime project and built the save-data targets with the actual libc/libkernel/save-data/dialog libraries.
• All 8 selected tests passed: guest_savedata_blocks, guest_savedata_search, guest_savedata_delete, guest_savedata_convert, guest_savedata_mount_status, guest_savedata_ps4, guest_savedata_cancel, and guest_savedata_dialog (0.21 s total, 30 s per-test limit).

An additional compatibility probe found a problem with allocation records produced by current main. Reproduction through the actual library:

1. Mount a new save with CREATE2|RDWR and 80 blocks.
2. Replace its adjacent .blocks file with the binary bytes 80\r\n.
3. Call sceSaveDataGetMountInfo.

On this PR, the process terminates with:

SaveData: blocks file _sd/NEWLINE.blocks is not a number

Exit code: 0xC0000409. The same probe executable against rebuilt main 31bfc4e86 succeeds and reports blocks=80 free_blocks=80. Main's keep_save_blocks writes the number followed by a newline using a text-mode stream, producing this CRLF format on Windows; this PR's directory_blocks rejects every non-digit byte.

Main has also merged #5094, which already records allocations, calculates free blocks, and deletes the sidecar. This PR currently conflicts in Export.cpp. The legacy-save behavior still differs: this PR infers a minimum 96-block allocation from usage, whereas main reports the maximum until a mount supplies an allocation. That difference needs to be reconciled separately from the newline compatibility fix.

For comparison, main's 7 corresponding save-data/dialog tests passed (0.57 s total); it does not register guest_savedata_blocks. This is targeted native Windows validation, not a complete runtime suite or Minecraft/title validation.

AI-assisted: yes (OpenAI Codex).

[adriadam10]

Closing: #5094 (merged today) already records the creating mount's block count in the same <dir>.blocks file and reports it from both sceSaveDataGetMountInfo and sceSaveDataDirNameSearch (save_blocks/search_info in Export.cpp), so this PR now conflicts with main in Export.cpp and duplicates that mechanism.

What is not on main is the fallback for a directory with no .blocks record (its files rounded up to the 96-block minimum instead of 32768) and create2 && !exists when recording. If you still want those, please reopen or send a small PR on top of current main with just that part, reusing the existing search_info helpers and a test that fails without it. The Conventions check on the current head is also red, so please check it when you rebase.