incomplete backups should not block delete or gc
Conserve 0.6.15 currently declines to delete or gc any content if the last band in the archive is incomplete:
https://github.com/sourcefrog/conserve/blob/5320ad926882a20bae54e1d61b0f7b0d76d25062/src/gc_lock.rs#L50-L62
https://github.com/sourcefrog/conserve/blob/main/doc/deletion.md
This is annoying in a couple of scenarios:
- If you discover the backup is including things that should be excluded, and you interrupt it, then you can't immediately remove the incomplete backup.
- Suppose the last backup is complete and the second-last is incomplete. If you delete the last backup, then you cannot then delete the incomplete backup.
Note that the policy does not just prevent deleting the last band; it prevents deleting anything if the last band is incomplete.
Basically, this is being used as a conservative detection of whether a backup might currently be underway.
The reason for this policy is that we want to make sure we're not writing a new backup concurrently with deleting data, which might lead to the new backup referencing blocks that are later deleted.
However this could possibly be handled another way, perhaps one of:
- Better indication whether a backup really is currently running. Possibly, the running backup should take a lock on the archive, not just gc.
- Deleting content in a way that is safe with a concurrent backup. (I'm not sure what that would be though.)