--verify removes a mismatched original before its replacement has been downloaded #199

New Issue

2026-10-14T09:29:22+02:00

clawbot commented

2026-10-14 09:29:22 +02:00

Severity: low

Where: storeOriginal in runLockedBackup, src/backup.ts: on a hash mismatch it removes the stored original (both files of a live photo) and only then calls placeOriginal to download it again.

Problem: when that download fails, the backup holds nothing for the file where it held a copy before, if one that did not match its hash. That is the outcome when the server answers 404 because the file is gone, when the CDN keeps failing past the retries, or when the new bytes do not match either. The README documents this order ("deleted ... and put back in the same run") and test/cli/backup.test.ts pins it ("records a failed download in failures.json, with the original removed"), so this is a judgement call rather than a contradiction: a mismatched copy of a photo is usually still mostly a photo, and a backup should not give up the only copy it has until it holds a better one. The download writer already writes to a temporary file beside the destination and renames it into place, so the old bytes can stay until the new ones are complete.

Done when: a mismatched original is replaced by the rename of its complete, hash-checked replacement, and stays as it was when the download fails (still recorded in failures.json, exit 1). A test: a mismatched original whose download answers 404 is still at its save path afterwards, with the old bytes.

Model: fable-5-1

Severity: low **Where:** `storeOriginal` in `runLockedBackup`, `src/backup.ts`: on a hash mismatch it removes the stored original (both files of a live photo) and only then calls `placeOriginal` to download it again. **Problem:** when that download fails, the backup holds nothing for the file where it held a copy before, if one that did not match its hash. That is the outcome when the server answers 404 because the file is gone, when the CDN keeps failing past the retries, or when the new bytes do not match either. The README documents this order ("deleted ... and put back in the same run") and `test/cli/backup.test.ts` pins it ("records a failed download in failures.json, with the original removed"), so this is a judgement call rather than a contradiction: a mismatched copy of a photo is usually still mostly a photo, and a backup should not give up the only copy it has until it holds a better one. The download writer already writes to a temporary file beside the destination and renames it into place, so the old bytes can stay until the new ones are complete. **Done when:** a mismatched original is replaced by the rename of its complete, hash-checked replacement, and stays as it was when the download fails (still recorded in `failures.json`, exit 1). A test: a mismatched original whose download answers 404 is still at its save path afterwards, with the old bytes. Model: fable-5-1

clawbot added this to the 1.0.0 milestone 2026-10-14 09:29:22 +02:00

clawbot referenced this issue

2026-10-14 09:32:15 +02:00

1.0: `v1.0.0-rc1` is a release candidate #201

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/quak#199

--verify removes a mismatched original before its replacement has been downloaded #199

`--verify` removes a mismatched original before its replacement has been downloaded #199