Repository navigation
Mac: keep game saves safe when the game library moves, a copy fails, or the drive is HFS+ - #1118
Open
MartinMajewski wants to merge 1 commit into
Open
MartinMajewski wants to merge 1 commit into
MartinMajewski wants to merge 1 commit into
Conversation
Owner
|
Heads up @MartinMajewski: #1120 just merged into |
MartinMajewski
force-pushed
the
fix/library-save-followup
branch
from
November 10, 2026 12:26
bef41e3 to
cd1e556
Compare
Contributor
Author
|
Thanks for the heads-up, @LNPANDY. It's rebased onto the current 🤖 Co-authored with Claude Code |
Closed
1 task done
MartinMajewski
force-pushed
the
fix/library-save-followup
branch
from
November 11, 2026 15:15
cd1e556 to
c53429b
Compare
…or the drive is HFS+ Patch 0031-mac-library-folder (0010 and 0112 from LNPANDY#920 and LNPANDY#1097, squashed) keeps a game's save in ~/Library when its game library is on a drive that can't hold saves. The review of LNPANDY#920 found three cases where it still loses progress, and the fixes never reached main. Patch 0046 adds them: - The launcher records which folder it last started the game from and brings that whole save along when the folder changes, so an older copy no longer wins after a library moves between drives. - The copy is all or nothing. An older save in the destination is kept aside, and a failed copy stops the launch with an alert and is tried again on the next start. - HFS+, which doesn't report the clone and swap bits, now falls back as the README says. The device save (<save>_device) moves with the save, and a save folder the launcher passes in DM_SAVE is used as it is and recorded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MartinMajewski
force-pushed
the
fix/library-save-followup
branch
from
November 13, 2026 12:50
c53429b to
c938615
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix or feature
What and why
Problem. The library folder patch, now
0031-mac-library-folder.patch(0010 and 0112 from #920 and #1097, squashed together) keeps a game's save in~/Librarywhen its game library is on a drive that can't hold saves. @thehobbit85's review of #920 found three cases where it still loses progress, and the fixes for them never reached main, because #920 was closed before I could push them.Cause. 0031 only copies a save into an empty folder, so an older copy can win after a library moves between drives. Its copy doesn't report failures, so the game can start on half a save. And HFS+ doesn't report the clone and swap bits, so 0031 treats it as able to hold saves.
Change. New patch
0046-mac-launcher-bring-the-last-played-save-along-al.patchon top of 0031, indm/mac/launcher.c:save-locationin the game's Application Support folder). When that changes, it brings the whole save along. Without a record, the library's save counts as current.<save>.migratingand is renamed into place only when every file arrived. An older save in the destination is kept as<save>.replaced-<time>. If the copy fails, an alert says why, the game doesn't start, and the next start tries again.statfsdecides, and only APFS keeps saves next to the game.Two things main gained since #920 are covered too. The device save (
<save>_device) moves together with the save. And a save folder the launcher passes inDM_SAVE(the per-game and global save folders from #1097) is used as it is, and only recorded.Checked
python3 tools/engine.py checkpasses (on0c078130).python3 -m unittest test_nsp_mac_appinengine/dm/tools/testspasses, 83 tests.frontend/andfrontend-qt/aren't changed.test_nsp_mac_app.App, and each one fails on the old 0112 behavior that 0031 still has:test_library_folder_on_hfs: a library on an HFS+ disk imagetest_library_save_beats_older_home_save: a newer library save wins over an older~/Librarycopytest_library_back_on_apfs: progress made in~/Library, device save included, follows the library to APFStest_library_save_copy_fails: a copy cut short by a file-size limit doesn't start the game, and the next start finishes ittest_library_save_chosen_by_the_front_end:DM_SAVEfrom the launch environment is used and recordedtest_library_folder_on_apfs: now also checks the record01006BB00C6F0000, 1.0.1) in an exFAT library started with this launcher on its~/Librarysave, and recorded it. I didn't run it again on today's main.Screenshots
None, no visible change in the launcher. The one new piece of UI is the game app's own alert when a save can't be copied.
Scope
dm/,scripts/,docs/,ref/) is added to the repository: a change there is a patch inpatches/(a commit inengine/, thentools/engine.py export, andtools/engine.py checkpasses), with itsUpstream-Statuspending.One thing I left out:
VolumeSaves.holdsSavesinfrontend/Sources/NXCore/SaveLocation.swift(from #1097) has the same HFS+ gap, so the launcher's save settings would show an HFS+ library as fine while the game falls back to~/Library. I can add that in this PR or a separate one if you'd like.🤖 Co-authored with Claude Code