Harden account and auth persistence with atomic writes#14
Harden account and auth persistence with atomic writes#14thatdaveguy1 wants to merge 1 commit intoLampese:mainfrom
Conversation
|
plz resolve the conflicts |
Lampese
left a comment
There was a problem hiding this comment.
Requesting changes for two behavioral issues:
-
The new
.lockfile approach can deadlock future writes after a crash.FileLockcreates a sibling lock file withcreate_new(true)and only removes it inDrop. If the process is killed or crashes after acquiring the lock, the stale.lockfile remains behind permanently, and every later write path will just time out waiting for it. That means the crash-hardening path introduces a new failure mode exactly in the scenario this PR is trying to improve. -
The new
.bakfiles are written, but none of the read paths actually use them for recovery.accounts.json.bakandauth.json.bakare created, but loading still reads only the primary file and fails immediately if it is corrupted or partially unreadable. So the backup mechanism currently increases file churn without providing an actual recovery path.
I think both issues should be addressed before merging, otherwise this change improves write atomicity but still leaves crash recovery incomplete and can also introduce stale-lock write failures.
Why
The account database and active auth file are written directly today. If the app crashes mid-write or multiple operations overlap, that can leave
accounts.jsonorauth.jsonin a partially written state.This PR hardens those persistence paths with atomic writes, simple locking, and backup files so storage updates are more crash-resistant.
What changed
fs_utils.rsfor locked atomic writesstorage.rsto use the new write path for account persistenceswitcher.rsto write active auth data atomically and emit.bakbackupsReviewer notes
Verification
cargo checkinsrc-tauripasses on this branch