Comment 46 for bug 680529

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/9/2011 3:18 PM, Alexander Belchenko wrote:
> ** Also affects: bzr
> Importance: Undecided
> Status: New
>
> ** Changed in: qbzr
> Assignee: canonical-bazaar (canonical-bazaar) => (unassigned)
>

If you are getting "Lock renamed into place, but now is missing", that
means that something might be *unlocking* the file behind our backs.

The other possibility with network systems is that we rename "pending...
to held", and that doesn't give us an error. But we follow that up
quickly with "open(held/info)", and that is failing.

It is *possible* that the network fs isn't being very atomic for us. And
it is letting the rename succeed, but not actually committing it/seeing
the update when we got to read afterwards.

What seems suspicious is that they are only seeing this behavior when
running 'bzr qcommit', and not from just 'bzr commit'.

I realize we used to deadlock. It makes me wonder, though, if the fact
that the new code tries to lock, and then aborts if it fails, isn't
causing poor behavior from the network mounted filesystem. (ie. the qbzr
logic is technically correct, but it causes the mounted filesystem to
misbehave.)

I don't know the specifics, as I've never been able to reproduce it. But
the fact that people say it reliably fails when run from 'bzr qcommit'
but reliably passes from 'bzr commit' at least hints to an interaction
causing the problem.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3w0NoACgkQJdeBCYSNAAMYXwCfSqVGd3rjvgJXQoCWiPNkuTR9
T+cAnj23BylwpihFWNqRIHGc47jiKxeQ
=jPni
-----END PGP SIGNATURE-----