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

[Aaron Bentley]

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

Kuno Meyer wrote:
> On 07.08.2007 06:21, Aaron Bentley wrote:
>> 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.
> 
> Nothing to be infuriated. Visual Studio just holds locks

My understanding is that Windows will not let you e.g. delete a file
that is open, regardless of whether or not the other client has
explicitly locked it.

This is completely legal, and very convenient, on most POSIX systems.

It is infuriating that there's no way of making the transform *succeed*
on win32, whereas, on UNIX, we can always succeed, assuming we have the
correct write permissions to the directories.  It is infuriating that
the best we can hope for on win32 is to sometimes succeed, and mostly
fail safe.

> on files that
> don't deserve version control

So you are saying that Visual Studio's Intellisense doesn't read actual
source files ever?

> (binaries and generated intermediate files
> with cached data), and versioning such files is clearly a mistake.

So you're saying Andrew King had versioned generated/intermediate files?

> It occasionally may happen that a user forgets to close such documents
> when running bzr

In Unix, there's no need to remember to close such documents when
running bzr.

> (as this may happen in other situations as well where
> file locks are being hold during a long time). Bazaar doesn't cope well
> even with the static case of locks constantly being hold.

Locks under Unix are typically advisory, not mandatory.

> And bug 67699 talks of write-protection flags as well.

Write-protection of files on Unix does not prevent renames, it prevents
 writes.

>> 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.
> 
> I'm sorry to say this, but implementing a rollback is way too much work
> for the time I have available for bazaar, based on a) my knowledge of
> cross-platform development, b) my knowledge of the internals of Bazaar
> and c) the complexity of TreeTransform. The TreeTransform class is in my
> opinion a bit underdocumented as well.

Your opinion is certainly valid, but I have done my best.  I have
documented most of the public methods and many private ones, too.  As
the main author of TreeTransform, I may not have the perspective needed
to update the documentation, but I would welcome advice or patches.

> So, I am considering to implement at least an improved treatment of
> write-protection flags:
> 
> 1) Write-protected files shall not break TreeTransform.finalize() (where
> the limbo dir gets cleared)

I don't think that changing finalize will change much.  If a transform
has been successfully applied, then there will be nothing in limbo anyway.

> 2) Newly created or modified files shall not have the write protection
> flag set (enforce chmod u+w)
> 
> Would this be acceptable an acceptable behaviour?

That is not necessary or desirable on UNIX.  In fact, we try to preserve
the existing file permissions if at all possible.  How would this help
on Windows?

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

iD8DBQFGuM690F+nu1YWqI0RAr4xAJ40PRn9PO2z+2f+Ya2wNMy1WHgLgACfVKnT
ZRuY+a6mLAIDNqkO+GpQK+4=
=22ri
-----END PGP SIGNATURE-----