The delete that didn't delete

The empty-folder check is a good safeguard, but I think there’s another failure mode worth considering: a stale build artifact.

Imagine a CI pipeline where a failed build leaves the previous dist/ directory intact. The deployment job still succeeds, runs rsync --delete, and removes pages and assets that were added in a newer release. The source directory isn’t empty, so the usual safety check won’t catch it.

Would it make sense to generate a manifest containing the build’s Git commit SHA and file hashes, then validate it against the intended release before calculating the deletion set? I’d also keep the previous release available for an atomic rollback. That way, the deploy process verifies not just that files exist, but that the source actually represents the version we intend to publish.

Rotating the key only makes the purged blocks unreadable once the old key is destroyed, and since Foxstash never holds the key, that last step sits with the app. NIST SP 800-88 Rev. 2 calls this cryptographic erase and defines it as sanitizing the keys, so recovery becomes infeasible because the old key is gone, not because a new one exists. If the meeting recorder keeps old keys around so it can still open older files, the deleted meeting is still recoverable from those blocks.

That runs into your retention default of 2. The old key can only go once no file on disk still needs it, so the order would be purge, rotate, then compact until the fallback checkpoint is also written under the new key, and only then destroy the old one. Destroy it too early and the fallback becomes a file nobody can open. Having the purge report list which key generation each surviving file was written with would tell the app when destroying the old key is safe.