Re: Dead lock in repository

[EricZolf]

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