Write recent.txt atomically

[lepht]

saveRecents() opens recent.txt with mode "w", which truncates the file before a single byte of the new list is written. On a handheld that window isn't theoretical — the power switch is right there, and losing power mid-write leaves a truncated or empty recents list behind.

Changes

• openAtomic() / commitAtomic() in workspace/all/common/utils.c, next to the existing putFile(). Write to a sibling .tmp file, fsync() it, then rename() over the target, so a reader only ever sees the whole old file or the whole new one. On failure the temp file is unlinked and the original is left untouched.
• saveRecents() uses them.
• tests/ with a unit test for utils.c, a make test target, and a CI job.

fsync() before the rename matters here: without it the rename can land while the contents are still only in the page cache, which on a yanked-power SD card is the same failure in a different disguise.

Tests

The original testing here covered the happy path only — create, grow, shrink — and asserted the failure behaviour from reading the code. The failure behaviour is the entire reason these functions exist, so it was the one thing that shouldn't have been taken on trust.

The load-bearing check forces rename() to fail by pointing it at a non-empty directory (which fails whether or not tests run as root), then asserts the original target and its contents are exactly as they were and the temp file is gone. Also covered: the truncated-path guard, an unopenable temp file, and a NULL handle being a safe no-op.

While the harness is there it also covers the pure helpers the menu leans on — suffixMatch (decides whether a multi-disc folder is keyed on its .m3u or .cue), containsString (is the rom search filter), prefixMatch, hide, getDisplayName, trimSortingMeta.

One asymmetry worth a reviewer's eye: exactMatch is case sensitive where prefixMatch and suffixMatch are not. hide() inherits that, so map.txt is hidden but Map.txt is not. Asserted as observed rather than endorsed, so if anyone changes it the test says so.

Why this is cheap

utils.c links against libc alone — no SDL symbols, no project symbols — so the test binary is just the two files, with SDL needed for headers only. Nothing opens a window. The CI job is native, takes about a minute, and sits alongside the builds rather than gating them so a red test reads on its own row.

Verified

$ make test
running utils tests
- openAtomic/commitAtomic write a new file
- a rewrite replaces the file whole, so a shorter one leaves no tail
- a failed commit leaves the original untouched
- openAtomic refuses a path with no room for the suffix
- openAtomic reports a temp file it cannot create
- prefixMatch / suffixMatch / exactMatch / containsString / hide
- getDisplayName / trimSortingMeta

all checks passed

Plus the original end-to-end run under Xvfb: cleared recent.txt and launched a game (file created, no .tmp), then launched a second from another system (113 → 176 bytes, newest at top, both intact).

One whitespace change

-Wall surfaced a -Wmisleading-indentation warning in getInt — mixed tabs and spaces, logic correct. Fixed the indentation so it doesn't fire on every test run; git diff -w over it is empty. Warnings that always fire are warnings nobody reads.

Note

The same atomicity fix applies to saveFavorites() in #1, which picks these helpers up from this branch rather than duplicating them.