Release the locks of a killed restore when it runs again; legacy test without empty folders

A killed restore left its leases for up to two hours, so the first backup of the recovered
server was refused. A backup from before 1.0.3 records no empty folders: the test now expects that.
This commit is contained in:
2026-11-06 17:34:33 +01:00
parent b14b16c66c
commit d96229f370
6 changed files with 38 additions and 7 deletions
+2
View File
@@ -24,6 +24,8 @@ shown under 1.0.0. The git tag of a release candidate goes after the date.
- A restore that goes on after a stop also removes the temporary files in folders where every file
is already in place, and checks that those folders are inside the restore directory before it
leaves their files alone.
- After a restore that was killed and then ran again, a backup no longer has to wait up to two hours
for the locks of the killed run.
- A restore only removes read-ahead folders of its own (`.ngb-restore-spool-` with 8 hex digits).
- A restore keeps its lock on the location during a long row of files that are already in place.
- A database restore that fails no longer leaves behind tables it created, which could stop the