sftp locks can get stuck

[John A Meinel]

Robey Pointer wrote:
> 
> On 20 Dec 2005, at 17:56, John Arbash Meinel wrote:
> 
>> Robey Pointer wrote:
>>>
>>> There are some heuristics we could do to cut out some cases.  For
>>> example, we could write the lock-owner's email address into the lock
>>> file, so that we could automatically recover from a stale lock that  was
>>> just left behind by one of your own previous sessions.  (It also  helps
>>> you figure out who to ping if you're on a shared project and  feeling
>>> conscientious.)
>>
>> True. But as long as you don't forget you can push from more than one
>> machine, though you are likely to serialize your access. (This may
>> become more likely once we get bound branches, since there will be more
>> remote access going on).
> 
> Yeah, so we should be storing both the email & the IP...  or is that
> getting into the area of diminishing returns? :)
> 
> 
>>
>>>
>>> If all writes are transactional (are they?), then we could add a lock
>>> check phase right before the final commit: make sure that we still  own
>>> the lock.  Assuming the final commit is short, that would let us  use a
>>> timeout of something much smaller, like 15 minutes.  That would  reduce
>>> the odds of needing to manually break a stale lock.
>>
>> For now they are atomic, but not transactional. Meaning you can get out
>> of order. 2 pushes are modifying branch.py-*.weave, they each create a
>> temporary file, and then one wins.
>> And if they both modify branch.py and clone.py, one might win one, and
>> the other would win the other.
> 
> Hm, I see.  Hence the need for the write lock. :)  Sorry, it took me a
> little while to digest what was going on.
> 
> I think simpler is better here:  We record tracking info in the write
> lock (email, IP, timestamp) and provide a way to explicitly break the
> lock.  Maybe if an operation fails because of a write lock, and that
> lock is pretty old (by some arbitrary standard), bzr could hint to the
> user:
> 
>     The branch was locked by <robey at lag.net> 5 hours ago.
>     If the lock is stale, you can break it with: bzr break-lock
> 
> But no magic of trying to guess if the lock should be automatically
> broken, etc.  Stale locks should be relatively rare.
> 
> robey
> 

I'm +1 for adding the username, and not automatically breaking the lock.
 I don't think the ip address helps much, but it is easy to record. I
don't think we need the timestamp, because we can just stat() the lock
file to figure out what time it was taken out. I suppose we could add
the UCT timestamp to help with handling time-zone shift.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051223/e86dd2d0/attachment.pgp