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:
@@ -110,6 +110,7 @@ final class RestoreFullService {
|
||||
// directory: once applied, 'secret' may differ from what ng_backup's own Target
|
||||
// options were encrypted with (see restoreFull()'s docblock), and every further
|
||||
// repository access through $this->targets would fail to decrypt them.
|
||||
/** @var array<string, mixed> $backupConfig */
|
||||
$backupConfig = $this->fetchBackupConfig($target, $snapshotId);
|
||||
|
||||
$dataDir = rtrim($this->config->getSystemValueString('datadirectory'), '/');
|
||||
|
||||
@@ -39,10 +39,10 @@ final class UserBackupService {
|
||||
$dest = new RepositoryExportDestination($repo, $user->getUID());
|
||||
$service->export($dest, $user);
|
||||
// A short exclusive lock around the catalog write only: the shared lock above
|
||||
// allows another concurrent backup (full or per-user) to be reading the same
|
||||
// catalog generation at the same time, and both writing the next one would let
|
||||
// one silently overwrite the other's addition.
|
||||
$this->withCatalogLock($target, fn () => $repo->recordUserExport($dest->manifestPath()));
|
||||
// allows another concurrent backup (full or per-user) to be writing the catalog at
|
||||
// the same time. The repository is reopened inside the lock, so the write builds on
|
||||
// the latest catalog generation instead of the one loaded before the lock was taken.
|
||||
$this->withCatalogLock($target, fn () => $this->targets->repository($target)->recordUserExport($dest->manifestPath()));
|
||||
return $dest->manifestPath();
|
||||
});
|
||||
}
|
||||
|
||||
@@ -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");
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user