sftp locks can get stuck

Jan Hudec bulb at ucw.cz
Wed Dec 21 09:56:56 GMT 2005


On Tue, Dec 20, 2005 at 10:15:17 -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. :(

Yes. The only solution is that breaking the lock actually makes the
transaction uncommittable like Arch did. 

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

Unfortunately current filesystems don't support transaction and the
transports even less so.

> Just free thoughts.  I can't think of anything that would completely  
> avoid the possibility of stale locks over a dumb transport.

Actually it's not possible to do reliable locking over network. Transaction
semantics is necessary.

Of all the available atomic syscalls, only directory rename behaves
consistently across all of posix, windows and nfs, ftp, webdav and sftp.
(nfs v2 and nfs on older linux before 2.6 does not support O_EXCL).

There is one problem I don't know how to handle reasonably. The knits can
simply be truncated on rollback. However if you are forcibly rolling back
another transaction and simply truncate them, you create a mess if the
transaction is still running. Or they can be copied, but that's proportional
to the size of the repository, which is not desirable. This is where grouping
by revision is better, because renaming in place will do then.

-- 
						 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/20051221/b87d4de5/attachment.pgp 


More information about the bazaar mailing list