Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: revlib locking

[Jan Hudec]

On Fri, Jun 04, 2004 at 22:20:58 +0200, Robin Farine wrote:
> On Friday 04 June 2004 20.56, Jan Hudec wrote:
> 
> > On Fri, Jun 04, 2004 at 15:41:13 +0100, Andrew Suffield wrote:
> 
> [...]
> 
> > > If the link succeeds and the link count on the lock file is 2,
> > > you have the lock. Otherwise you missed: delete the lock file
> > > and your temporary file, wait a random interval, and try again.
> 
> I would say this is wrong.
> 
> > Still the same.
> 
> No, if one cared about the success of the link operation, then one 
> would not need a temporary file. The successfull creation of a hard 

Hell, that's what we talk about whole day! *YOU* *CAN'T* *RELY* *ON*
*THE* *RETURN* *VALUE*.

> link to a well-known existing file would suffice to acquire the 
> lock. And if the result of the link operation is not reliable, then 
> testing the link count of the lock file does not help at all.

It does. If you are the only one trying to link something to a specified
file, than it's link count can only ever increase if YOU succeed. And
that's what you want to know.

> What Julian initially proposed was to consider the link count of the 
> _temporary file_ which being 2 implies that the link operation 
> succeeded. This assumes that one can ensure name uniqueness.

That assumption is true, though a little tricky. Client ID + PID on that
client are guaranteed to be unique. But you should to get the client
address as seen by the server, because there might be a masquerade in
between (and break the uniqueness).

> Also, when the lock attempt fails, only the temporary file should be 
> removed, not the lock file.

When lock attempt fails, you don't own the lockfile. So you, obviously,
shouldn't delete it.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature