Found during the /plan-eng-review of #45 (outside voice).
create_rclone_remote reads rclone.conf (backend/backup/cloud_auth.py:149) and writes it back (:176) — a read-modify-write of a file rclone itself rewrites whenever it refreshes an OAuth token. sync_token_from_rclone (:240) exists only because of that.
Worse: restore_rclone_config (:225-237) runs at every startup and writes the possibly-stale DB token back over whatever rclone last refreshed.
#45 makes those writes atomic (D4), which makes the clobber indivisible rather than preventing it. That is worth saying out loud so the atomicity work is not mistaken for a fix.
Fix: treat rclone as the owner of the token in rclone.conf and read through to it, or hold a lock across the read-modify-write, or stop rewriting sections rclone manages.
Related: #45.
Found during the /plan-eng-review of #45 (outside voice).
create_rclone_remotereadsrclone.conf(backend/backup/cloud_auth.py:149) and writes it back (:176) — a read-modify-write of a file rclone itself rewrites whenever it refreshes an OAuth token.sync_token_from_rclone(:240) exists only because of that.Worse:
restore_rclone_config(:225-237) runs at every startup and writes the possibly-stale DB token back over whatever rclone last refreshed.#45 makes those writes atomic (D4), which makes the clobber indivisible rather than preventing it. That is worth saying out loud so the atomicity work is not mistaken for a fix.
Fix: treat rclone as the owner of the token in
rclone.confand read through to it, or hold a lock across the read-modify-write, or stop rewriting sections rclone manages.Related: #45.