[RFC] making TreeTransform more resistant to unexpected failures / writing problems

[Aaron Bentley]

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

Kuno Meyer wrote:
>   https://bugs.launchpad.net/bzr/+bug/67699

I am infuriated by the way Windows conflates opening a file with locking
it, and this is exacerbated by Visual Studio's habit of opening files at
random.

> One option to solve this behaviour is to check the assumed preconditions
> before actually performing the queued operations.

That doesn't solve the behavior.  That creates a race condition, in
which sometimes the behavior is solved, and sometimes it is not.  I
expect that in the Visual Studio case, Visual Studio will open a new
file before the transform completes.

> 1) The easiest way to determine the writability would be to effectively
> trying to write into the file (or when necessary, temporarily creating it).
> 
> - This would be quite easy to implement and
> - would cover all necessary issues like writing permissions on
> directories on unix and exclusive file access.
> - The cost of this operation is not that high

This would double the cost of tree creation, which I consider an
unacceptable cost.  We are trying to make tree creation faster, not slower.

> 2) Another possibility would be to use the platform-dependent locking
> techniques (fcntl.flock / win32file.LockFileEx) to check writability,
> but then we have the problem with the directory permission flags under
> Unix.

I think holding open locks on all affected files during the transform is
an unacceptable resource waste.

Failing to hold all the locks during the transform would lead to races.

> What is your opinion?

I think that you can't predict whether this failure mode will occur.
The only thing you can hope to do is recover gracefully when it does
occur, e.g. by rolling back the transform or retrying the operation.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGt/Nl0F+nu1YWqI0RAjmVAJ9IIxZJv7ah2AMF5m1spcXcitX2eQCeL3tx
4BPUDF+qLmygjtthcaYMMI4=
=RIg2
-----END PGP SIGNATURE-----