Fix review findings: catalog writes, user restore consent, retention validation

Catalog: forgetting a user export or purging trash now writes the catalog
before deleting the objects, so a crash leaves at most an unreferenced file
instead of a catalog entry pointing at nothing. Per-user backup and the
safety export reopen the repository inside the catalog lock, so they build
on the latest catalog generation.

Commands: backup:user:backup and backup:user:restore resolve the location
before asking to install user_migration, and a successful install always
stops with a rerun instruction. backup:retention rejects a malformed
--user-last before changing any policy. backup:key:import fails clearly
when the passphrase file cannot be read.
This commit is contained in:
2026-10-06 17:40:51 +02:00
parent 614caf9f63
commit eb9100a74d
9 changed files with 35 additions and 30 deletions
+3 -3
View File
@@ -83,9 +83,9 @@ final class UserRestoreService {
$safety = new RepositoryExportDestination($repo, $originalUid);
$service->export($safety, $existing);
$safetyManifestPath = $safety->manifestPath();
// Same race as UserBackupService::backupUser(): serialize the catalog write
// itself against any other concurrent backup/restore for this target.
$this->withCatalogLock($target, fn () => $repo->recordUserExport($safetyManifestPath));
// Same race as UserBackupService::backupUser(): reopen the repository inside the
// catalog lock so the write builds on the latest generation.
$this->withCatalogLock($target, fn () => $this->targets->repository($target)->recordUserExport($safetyManifestPath));
if (!$existing->delete()) {
throw new \RuntimeException("Could not delete the existing account $originalUid before restoring; its safety export is at $safetyManifestPath");
}