2021-11-20 16:48:22 +01:00
|
|
|
Enhancement: Stricter repository lock handling
|
2021-11-14 17:52:41 +01:00
|
|
|
|
|
|
|
|
Restic commands kept running even if they failed to refresh their locks in
|
|
|
|
|
time. This can be a problem if a concurrent call to `unlock` and `prune`
|
|
|
|
|
removes data from the repository. Not refreshing a lock in time can for example
|
|
|
|
|
be caused by a client switching to standby while running a backup.
|
|
|
|
|
|
|
|
|
|
Lock handling is now much stricter. Commands requiring a lock are canceled if
|
|
|
|
|
the lock is not refreshed successfully in time.
|
|
|
|
|
|
2021-11-20 16:48:22 +01:00
|
|
|
In addition, if a lock file is not readable restic will not allow starting a
|
|
|
|
|
command. It may be necessary to remove invalid lock file manually or using
|
|
|
|
|
`unlock --remove-all`. Please make sure that no other restic processes are
|
|
|
|
|
running concurrently.
|
|
|
|
|
|
2021-11-14 17:52:41 +01:00
|
|
|
https://github.com/restic/restic/issues/2715
|
|
|
|
|
https://github.com/restic/restic/pull/3569
|
