sftp locks can get stuck

[James Blackwell]

On Tue, Dec 20, 2005 at 10:15:17AM -0800, Robey Pointer wrote:
> 
> On 19 Dec 2005, at 19:32, Robert Collins wrote:
> 
> >regrettably I just ran into a situation with a
> >stale .bzr/branch-lock.write over sftp.
> >
> >Is there any mechanism we can use with sftp to ensure that we dont get
> >stale locks/can remove them as needed?
> >
> >(I.e. write a time stamp and nuke it after 24 hours?)
> 
> There's of course a race in adding a timeout, but once you have a  
> stale lock it may be unavoidable. :(
> 
> 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.)

I think that automatically breaking the lock "if you are you" is probably
ok. That said, there's another thread going on right now about how
reliable automagically determining email address is. 

> 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.

Leaving asside the more important question for the moment, 15 minutes
isn't currently sufficient for dialup users.


> Just free thoughts.  I can't think of anything that would completely  
> avoid the possibility of stale locks over a dumb transport.
> 
> robey
> 
-------------- 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/20051221/462fe605/attachment.pgp