sftp locks can get stuck

[Robert Collins]

On Wed, 2006-01-04 at 09:19 +0100, Jan Hudec wrote:

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

Actually, arch renamed an *existing* dir to take out the lock, the
theory being that NO fs on the planet is silly enough to let two people
rename 'foo' to 'foo-something-unique' and have both succeed. (whereas
its conceivable that two renames could both succeed, one to the dir and
one into the dir.


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

Actually, because of the need to annotate historical data, it is not as
easy as I think you think it would be - arch had massive problems due to
that - it was only transactional for part of its operation.
Transactional and isolated files are really very orthogonal - look at
most fast, commercial grade databases for instance.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060104/5c912283/attachment.pgp