snapshots: never of a save a sync is writing, never incomplete by ChakraFusion · Pull Request #54 · Liquid-co/OpenSave

ChakraFusion · 2026-10-14T02:40:58Z

As offered in #21. Builds on #23 (own writes), which it needs for the watcher's own/other classification.

A pull of a save of many files overflowed the watcher's event queue again and again, and each overflow was taken for the game saving: up to 76 automatic snapshots of a half-pulled save for one pull. An overflow while a sync is writing the game, or was a moment ago (BeingWritten), is now taken for the sync's. A burst is looked at only once no sync is writing the game at that moment (WritingNow), so a change the game makes right after a pull is still snapshotted at once.
A snapshot that couldn't read every file is discarded rather than kept as a save that never existed.
*.opensave.tmp files are never archived.

(The fork version also limits #26's "mirror the peer's snapshot when already in sync" to games without history. That part will follow #26.)

🤖 Generated with Claude Code

vercel · 2026-10-14T02:41:04Z

@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

ChakraFusion · 2026-10-15T12:51:28Z

Rebased onto today's dev-public as you asked: with #23 merged, this is now the one commit of its own. The watcher conflict resolved itself in the rebase. Watcher, snapshot, syncengine and daemon tests, TestConflictNeverLosesPeerData and the watch e2e tests pass locally.

Omar-VF · 2026-10-16T13:03:17Z

Thanks. The first half (an event overflow during a sync taken for the sync's) is good. One concern with discarding incomplete snapshots: a game that holds a file open the whole time it runs (a log or lock file) would then have every snapshot discarded while it runs, and since the safety copy before a sync fails too, the sync stops replacing files, all quietly. Could incomplete snapshots be discarded only for automatic ones, keeping the safety copy before a sync even if a file couldn't be read (as it was before)? And if a game's automatic snapshots keep failing, say so plainly rather than only in the log.

… screen Asked in review: discarding every snapshot that could not read a file also discarded the copy kept before a sync replaces the save, and the sync then did not replace anything, quietly, for as long as a game held a file open (a log, a lock file). - Only the watcher's automatic snapshot (snapshot.CreateAutomatic) is discarded when it misses files; the watcher takes the change again at its next pass. Every other snapshot, the copy before a sync, restore or conflict above all, and one taken by hand, is kept with what could be read and a warning in the log, as before Liquid-co#54. - When a game's automatic snapshots come out incomplete three passes in a row, it is said on screen once, until one succeeds again: the files the game holds open, and that its changes are not backed up or synced until they can be read, usually once the game is closed. The text is in the catalogs (en, zh-CN), with a "common.open" key for the toast's button. Tests: an incomplete automatic snapshot is discarded, while one before replacing and one by hand are kept (a seam on the archive's file open makes a file unreadable on any system); the notice comes once per run of incomplete passes, again after a good snapshot, and never for other failures; the notice's wording, with the files beyond the first three counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ChakraFusion · 2026-10-16T15:38:24Z

Good catch, thank you. Done (618d0cd):

Only the watcher's automatic snapshot is discarded when it misses files (snapshot.CreateAutomatic). The copy before a sync, restore or conflict, and snapshots taken by hand, are kept with what could be read and a warning, as before snapshots: never of a save a sync is writing, never incomplete #54.
When a game's automatic snapshots come out incomplete three passes in a row, a toast says so once, until one succeeds again: which files the game holds open, and that its changes aren't backed up or synced until they can be read, usually once the game closes. The text is in the catalogs (en, zh-CN).

Tests: discarded vs kept, per kind of snapshot (a seam on the archive's file open makes a file unreadable on any OS); the notice once per run, again after a good snapshot, never for other failures; its wording.

Omar-VF · 2026-10-17T13:50:00Z

Thanks, the changes look good and it's approved. Merging #55 just now conflicts with this in en.json and zh-CN.json. Could you rebase onto dev-public? We'll merge it as soon as it's green.

A pull of a save of many files overflowed the watcher's event queue again and again, and each overflow was taken for the game saving: an automatic snapshot of a half-pulled save every few seconds - 76 on one device for one pull - which pushed the complete ones out of retention. - The watcher asks whether a sync is writing the game (BeingWritten). If so, an overflow is taken for the sync's, and the burst is looked at only once the sync has finished. - A snapshot that could not read every file is discarded, not kept: it would stand in the history as a save that never existed. The watcher leaves the change unrecorded and takes it again at its next pass; a sync that needed the copy before replacing files does not replace them. - OpenSave's own temporary files (*.opensave.tmp) are never archived. Builds on the own-writes change (Liquid-co#23). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… screen Asked in review: discarding every snapshot that could not read a file also discarded the copy kept before a sync replaces the save, and the sync then did not replace anything, quietly, for as long as a game held a file open (a log, a lock file). - Only the watcher's automatic snapshot (snapshot.CreateAutomatic) is discarded when it misses files; the watcher takes the change again at its next pass. Every other snapshot, the copy before a sync, restore or conflict above all, and one taken by hand, is kept with what could be read and a warning in the log, as before Liquid-co#54. - When a game's automatic snapshots come out incomplete three passes in a row, it is said on screen once, until one succeeds again: the files the game holds open, and that its changes are not backed up or synced until they can be read, usually once the game is closed. The text is in the catalogs (en, zh-CN), with a "common.open" key for the toast's button. Tests: an incomplete automatic snapshot is discarded, while one before replacing and one by hand are kept (a seam on the archive's file open makes a file unreadable on any system); the notice comes once per run of incomplete passes, again after a good snapshot, and never for other failures; the notice's wording, with the files beyond the first three counted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A game that keeps its settings beside its saves had one PC's graphics settings handed to every other: Crimson Desert's save/user_engine_option_save.xml, among others. The game database (Ludusavi manifest) already says which files are a game's settings: it tags them "config", as opposed to "save" - 16,700 entries. The index now keeps those (indexedGame.Config, index format v3, rebuilt once), and for each tracked game the ones inside its save folder become exclusion patterns relative to it (presets.DeviceSettings), matched component by component so a template's <storeUserId> wildcard meets the folder actually tracked. An entry tagged both is a save. A pattern that would cover the whole folder is never applied: a wrong exclusion loses saves, a missed one only syncs a setting. They are applied as the game's exclusion rules are, through one function everything that applies rules now takes them from (syncengine.Engine.IgnoreText), exactly like Liquid-co#52's launcher files: never synced in either direction, never deleted on another device, still in every snapshot, and kept on this device by a restore. The game's own rules come after them, so a "!" line brings one back; a per-game switch (games.sync_device_settings, migration 0040, "Sync these settings between devices too" in the configuration tab, with the files listed) syncs them all. The tab's new text is in the catalogs (en, zh-CN). The list changes without anyone writing a rule, at the first start with this build, so at start a game's last-snapshot hash is re-taken under the new list where the save is the one it was recorded for (daemon.adoptExclusionView); otherwise the watcher would snapshot and sync a game nobody played. The base agreed with each device needs nothing: the sync engine already translates a base recorded under other exclusions (Liquid-co#52). Toggling the switch goes through the same path as editing the rules. On top of Liquid-co#54, so the two merge one after the other (Liquid-co#52 is merged). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ChakraFusion · 2026-10-17T15:13:00Z

Rebased onto dev-public (4dfe3f2). The only conflict was the two catalogs, where #55's restore-progress keys and this PR's keys met at the end; both are kept. Unit, frontend and the related e2e tests pass locally.

Entries for Liquid-co#90, Liquid-co#78, Liquid-co#80, Liquid-co#54, Liquid-co#52, Liquid-co#94 and Liquid-co#79 under Fixed; Liquid-co#84, Liquid-co#55, Liquid-co#53 and Liquid-co#74 under Changed; Liquid-co#73 under Added.

ChakraFusion mentioned this pull request Oct 14, 2026

Fixes and improvements from running 2.4.1 on 4 PCs with large saves — how would you like them? #21

Open

ChakraFusion force-pushed the pr/snapshot-safety branch from 9073ebb to 1c40ee3 Compare October 15, 2026 12:51

ChakraFusion force-pushed the pr/snapshot-safety branch from 1c40ee3 to 618d0cd Compare October 16, 2026 15:16

This was referenced Oct 16, 2026

bug(syncengine): additional-root pulls and deletions bypass pre-replacement safety snapshots #82

Closed

bug(syncengine): additional-root conflict resolution can overwrite saves or discard conflict state #83

Closed

This was referenced Oct 17, 2026

Keep each device's game settings out of sync #84

Merged

i18n: offer Chinese by script (zh-Hans/zh-Hant) and extract the window shell #77

Merged

ChakraFusion and others added 2 commits October 17, 2026 16:35

ChakraFusion force-pushed the pr/snapshot-safety branch from 618d0cd to 4dfe3f2 Compare October 17, 2026 14:40

Omar-VF merged commit dee773d into Liquid-co:dev-public Oct 19, 2026
10 of 11 checks passed

Omar-VF mentioned this pull request Oct 19, 2026

Changelog: the thirteen PRs merged into dev-public since #76 #95

Merged

Navigation Menu

Repository navigation

snapshots: never of a save a sync is writing, never incomplete - #54

snapshots: never of a save a sync is writing, never incomplete#54
Omar-VF merged 2 commits into
Liquid-co:dev-publicfrom
ChakraFusion:pr/snapshot-safety

ChakraFusion commented Oct 14, 2026

Uh oh!

vercel Bot commented Oct 14, 2026

Uh oh!

ChakraFusion commented Oct 15, 2026

Uh oh!

Omar-VF commented Oct 16, 2026

Uh oh!

ChakraFusion commented Oct 16, 2026

Uh oh!

Omar-VF commented Oct 17, 2026

Uh oh!

ChakraFusion commented Oct 17, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

ChakraFusion commented Oct 14, 2026

Uh oh!

vercel Bot commented Oct 14, 2026

Uh oh!

ChakraFusion commented Oct 15, 2026

Uh oh!

Omar-VF commented Oct 16, 2026

Uh oh!

ChakraFusion commented Oct 16, 2026

Uh oh!

Omar-VF commented Oct 17, 2026

Uh oh!

ChakraFusion commented Oct 17, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants