Is there anything that blocks this small change from getting merged?

I'm not really sure about the design. Is it really the right way to blindly retry an operation lots of times?

One problem I see is that with infinite retries the shutdown of restic won't work properly in case of errors: e.g. removing a lock file might retry forever preventing restic from exiting. A similar behavior shows for other operations that can fail permanently.

I'm not really sure about the design. Is it really the right way to blindly retry an operation lots of times?

I do not question whether it is a good design to often retry or not. However, in the actual implementation restic retries 10 times and a specific total amount of time before giving up. As timings always can depend on the environment used, I would prefer to have user-definable setting with a sensible default value.

One problem I see is that with infinite retries the shutdown of restic won't work properly in case of errors: e.g. removing a lock file might retry forever preventing restic from exiting. A similar behavior shows for other operations that can fail permanently.

I agree that infinite trying is a bad idea. I propose the following:

• only allow positive values to --retry
• if the number is too large (e.g. > 20), print out a warning that restic may have to wait a long time to really quit in case of errors.

* only allow positive values to --retry

* if the number is too large (e.g. > 20), print out a warning that restic may have to wait a long time to really quit in case of errors.

This is now implemented.

The warning message is now corrected.