New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
forget --dry-run
fails if it can't take a lock
#4710
Comments
If a concurrent process modifies a repository, then the size statistics reported for |
No, This situation should take a readonly / non-exclusive lock. E.g.: like the lock taken by |
I'll think about it after finishing #4709 .
A non-exclusive lock doesn't prevent adding new data to the repository. Thus, a prune dry-run won't provide accurate statistics in that case (unless acquiring an exclusive lock first). |
Output of
restic version
What backend/service did you use to store the repository?
Problem description / Steps to reproduce
$OLDREPO
to$NEWREPO
withrestic copy --from-repo $OLDREPO -r $NEWREPO
$OLDREPO
withrestic -r . forget 5e7a252d --dry-run --prune
.EDIT: step (2) must be executed while the first one is still running. In my case, the
restic-copy
command has been running for an hour and has another hour left, so it's easy to reproduce.Expected behavior
This should work fine; a
--dry-run
does not need to mutate the repository, and the lock held byrestic-copy
should be non-exclusive (e.g.: other processes should be allowed to read the repository concurrently).Actual behavior
Do you have any idea what may have caused this?
I think that usually
forget
uses an exclusive/rw lock, but should not use such a lock when running with--dry-run
.Did restic help you today? Did it make you happy in any way?
Yes, it's been super convenient. Thanks for all the hard work!
The text was updated successfully, but these errors were encountered: