sftp locks can get stuck

[Jan Hudec]

On Tue, Jan 03, 2006 at 18:53:45 -0600, John Arbash Meinel wrote:
> Robert Collins wrote:
> > On Tue, 2006-01-03 at 18:33 -0600, John Arbash Meinel wrote:
> > 
> >>Except FTP doesn't do any locking. As far as I know it doesn't even
> >>support O_EXCL to lock the same way sftp does. 
> > 
> > 
> > My point is that we have a writable FTP transport: locking should be
> > figured out for it too. And that means we have 3 different sets of
> > features that need locking to be interact.
> > 
> > directory renames anyone ?
> > 
> > Rob
> > 
> 
> We certainly can do that. Is it sufficient to do something like:
> 
> # take lock
> rename('lock', 'locked')
> try:
>   # do stuff
> finally:
>   rename('locked', 'lock')
> 
> The first rename would fail if the source didn't exist.
> 
> My understanding of why tla had to do the double-deep directory renaming
> was because it wanted changes to disappear if the lock was broken.

The arch solution had one big advantage. If the lock was broken under a
still living client, the client failed and did not screw up. Because it
was a proper transaction. Solution that would be proper transaction
should be prefered IMHO.

> I thought there was also some way of doing locks with hard links, but
> that also wouldn't be terribly portable.

Yes. It is how traditional mail folder locks are done. Create a
temporary file (with unique name), link it to the lock and read link
count on the temporary. If it is 2, then you got the lock. This (and
clever directory renaming) is the only one that works on NFS. Because v2
did not support O_EXCL and it really does not work in v3 either. The
problem is, that the reply packet may be lost and the syscall returns
failure, but the link is actually created. But reading link count of
your temporary is reliable way to find out what the server actually did.

The directory renaming scheme would be: create a uniquely named
directory, create a uniquely named file in it, rename the directory to
the lock and look whether it contains your uniquely named file (again,
return value of network operation is never reliable).

Now to proper transactions. Arch had it easy, because it created a new
directory for each revision and all of the revision was stored there. So
it commited (the transaction) by renaming to the final name.

On POSIX system there is a schema to replace (Arch did not replace, it
only added) several files at once. But it requires symlinks and
posix-style file rename, which atomically replaces the old file. Neither
of which works on Windows.

I can perhaps think of a commit schema (one where transaction can be
forced to roll back in a way the writer won't damage anything), but it
might cause readers to fail.

I know you turned down the idea of grouping data (in knits - won't work
for weaves) by revision instead of by file for performance reasons. But
it would have one advantage -- transactions would be easy.

-- 
						 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/20060104/52899557/attachment.pgp