Re: Dead lock in repository

Hi,

> On 02/01/2023 00:56, Robert Nichols wrote:
>> I got a message that another rdiff-backup process with PID xxxx was 
>> running in that archive, coupled with a warning that running two 
>> rdiff-backup processes simultaneously could result in severe 
>> corruption of the archive. rdiff-backup then suggested that running 
>> with "--force" would bypass the restriction, and exited with an error 
>> status. As I said, that PID did not exist on either the client or the 
>> server. In fact, there was no other rdiff-backup process running 
>> anywhere on my network. I looked for a possible ".lock" file and did 
>> not find any. There was an empty "lock.xxx" (I forget what "xxx" was), 
>> which I tried removing, to no avail.

Sorry, my bad, the lockfile is named indeed 
`rdiff-backup-data/lock.yml`, but I still need more information to 
repeat the issue.

>> I'm paraphrasing since I don't have the original message, and my 
>> workaround was to rsync the entire archive from a stored copy.
>>
>> Unfortunately, "--force" is a bit too heavy a hammer to be wielding 

Agreed, I'm also thinking about having a more fine-tunable approach 
something like `--enforce unlock,somethingelse,etc`

>> for this situation, as it would also override other conditions that I 
>> wanted to respect. I'm locking that server to rdiff-backup-2.0.5 since 
>> that seems to be the last working version for me.

Locking is only done with API 201, so keeping 2.2.0 without 
--api-version 201 should work as well for you.

API 201 isn't the default for a reason, so I encourage anybody to try 
it, but API 200 is more tried and tested so far. API 201 will become the 
default though in the next version and if nobody has tried it properly, 
it will be of poor(er) quality.

KR, Eric