forget --dry-run fails if it can't take a lock

[WhyNotHugo]

Output of restic version

restic 0.16.4 compiled with go1.21.6 on linux/amd64

What backend/service did you use to store the repository?

a regular directory

Problem description / Steps to reproduce

1. Copy some snapshots from $OLDREPO to $NEWREPO with restic copy --from-repo $OLDREPO -r $NEWREPO
2. Try to determine the size of a single snapshot on $OLDREPO with restic -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 by restic-copy should be non-exclusive (e.g.: other processes should be allowed to read the repository concurrently).

Actual behavior

enter password for repository: 
repository 0123abcd opened (version 2, compression level auto)
repo already locked, waiting up to 0s for the lock
unable to create lock in backend: repository is already locked by PID 12184 on hyperion.whynothugo.nl by hugo (UID 1000, GID 1000)
lock was created at 2024-02-25 13:33:30 (15.059925447s ago)
storage ID 0123abcd
the `unlock` command can be used to remove stale locks

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!

[MichaelEischer]

forget --dry-run --no-lock does what you want.

If a concurrent process modifies a repository, then the size statistics reported for prune will be inaccurate.

[WhyNotHugo]

No, --no-lock doesn't do what I want, it avoids taking a lock altogether (this might result in my trying to run the above command on a storage that is actually being modified concurrently).

This situation should take a readonly / non-exclusive lock. E.g.: like the lock taken by restic-mount.

[MichaelEischer]

I'll think about it after finishing #4709 .

(this might result in my trying to run the above command on a storage that is actually being modified concurrently).

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).