Repository navigation
Steam's remotecache.vdf is the launcher's file, not a save change - #52
ChakraFusion wants to merge 1 commit into
Conversation
Steam rewrites remotecache.vdf in a game's userdata folder on every start. It counted as a new save: an automatic snapshot of a game nobody played, a sync to every other device, and where the folder is under Program Files a copy that failed with "access denied" on every pass. It is Steam's record of what Steam Cloud uploaded for this device, not part of the save. - delta.NeverSynced names such files (remotecache.vdf for now). - syncengine: they are left out wherever decisions are made, exactly like an exclusion rule - one check, excluded(), used by filterManifest, filterLineage, filterPathList and the recorded deletions. The filter now runs whether or not the game has rules of its own, and the translation of a base recorded before a rule existed runs always too, so a base recorded while the file still counted is not read as both sides moving. The manifest a device serves still lists the file: a device on an older build must not read the gap as a deletion. - watcher: such files do not wake it and do not count toward the content hash. A hash recorded by an earlier build, which counted them, is recognised once and re-taken, so the update itself is not snapshotted as a change. No migration needed. - An emptied-folder hold does not wait for such a file to come back. Tests: delta.NeverSynced; the content hash with and without rules, and the hash an older build recorded; left alone on both sides, still served, one-sided is no difference; e2e: Steam rewriting the file on one device is no snapshot and changes nothing on the other, while a real save change still syncs. Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
@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. |
|
The failing job is The test passed on every run of this branch on my fork, 8/8 locally, and 50/50 with the race detector on Windows runners. It's a rare timing flake, and a re-run of the failed job should pass. I'm still trying to catch it with the daemons' logs, and will open a separate fix if I find the cause. |
|
Follow-up: I caught that failure with the daemons' logs (once in 150 race-detector runs), and it's a real bug, not the test. The deck took an automatic snapshot of a save it had already kept: a newly tracked game had no recorded baseline, so writing a log into its excluded folder counted as a change. That copy was then the deck's newest save, so the desktop's newer one wasn't offered. It's unrelated to this PR. The fix is #56. |
This branch has not been deployed
1 participant
As offered in #21. Steam rewrites
remotecache.vdfin a game's userdata folder on every start. It counted as a new save: an automatic snapshot of a game nobody played, and a sync to every other device. Worse, the new e2e test shows that ondev-public, two PCs whose Steam keeps different bookkeeping read as diverged, so a real save change on one of them never reached the other.delta.NeverSyncednames such files (remotecache.vdffor now).excluded()check used byfilterManifest,filterLineage,filterPathListand the recorded deletions. The filtering now runs whether or not the game has rules of its own, and so does the translation of a base recorded before a rule existed. That way a base recorded while the file still counted isn't read as both sides moving.Tests:
delta.NeverSynced; the content hash with and without rules, plus the hash an older build recorded; left alone on both sides, still served, one-sided is no difference; e2eTestLauncherFile_SteamRewritingRemotecacheIsNoSaveChange, which fails ondev-public.🤖 Generated with Claude Code