Re: Dead lock in repository

Hi Robert,

were you able to reproduce the issue with the "persistent lock"?

Is Windows involved in this issue by chance? I had the issue during 
early phases of my development, that stopped processes were still 
recognized as running under Windows.

KR, Eric

On 02/01/2023 07:55, Eric Zolf wrote:
> 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
>