lock-breaking ui

[Jan Hudec]

On Tue, Feb 21, 2006 at 16:31:10 +1100, Martin Pool wrote:
> On Tue, 2006-02-21 at 10:43 +1100, Robert Collins wrote:
> 
> > 'open file descriptor' is not something we can do except locally.
> 
> Nor are hardlinks, fwiw.
> 
> > > I think the unlocking race condition is potentially very dangerous. I
> > > don't want a bogus client who was sitting on a lock to unlock me,
> > > after
> > > I've broken their control.
> > 
> > so the race is:
> > client A locks
> > client A starts to unlock and verifies it has the lock
> > client B breaks
> > client B locks
> > client A unlocks

So client A lost the lock, exactly as client B did just a while ago. That's
the same.

> This is just one case of bad things that can happen if you remove a
> supposedly stale lock while a client still thinks it has it.  Even aside
> from the problem of that client removing someone else's lock, it can
> still keep on modifying files while someone else is also doing so,
> causing havoc.
> 
> Therefore perhaps we do just have to assume that you only break a lock
> if you really are sure no one else holds it.  This is not perfect, but
> only the same requirement as cvs and svn (and arch?)

No. Arch had correct transactions - you could force a rollback and it did not
screw anything.

For that matter AFAIK subversion's fsfs does as well -- though that is never
accessed over ftp or sftp, so it's a bit simpler.


I was actually thinking that perhaps keeping some log in the lock would help.
In that the client who breaks the lock would know which files were written,
or about to be written, by the client who held the lock, and could clean (or
even be required to) up a bit.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060222/588cfc52/attachment.pgp