[MERGE] AtomicFile names are now not invariant-per-process which stops multiple transactions on the same file breaking under unknown conditions on Windows CIFS shares

[John Arbash Meinel]

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

Adrian Wilkins wrote:
> Fixes a problem with Windows where some clients run into ERR 17
> (errno.EEXIST) under circumstances that are unknown, but involve a
> repository on a CIFS/SMB network drive being accessed using the local
> transport. This would happen reliably, but only from certain clients, when
> 
>  * Branching a branch in the network drive to another branch on the
> network drive. (last-revision file).
>  * Autopacking (but not manual-packing)  (pack-names file)
> 
> The patch contains no changes to tests because it makes a small change
> to the internal implementation of AtomicFile in a way that should not
> affect the behaviour of the API.
> 
> The problem appears to be that the client requests deletion of the
> intermediary "AtomicFile" and the server responds that it has succeeded
> - and then the client creates the same file again, before the server has
> actually deleted it, causing an error.
> 
> Because I can't fix the race conditions in the Win2k3 CIFS server, the
> solution has been to add a random element to the filename that
> AtomicFile uses.
> 
> See
> 
> https://bugs.launchpad.net/bzr/+bug/304023
> 

This seems fine, though it seems like it would be good to understand why
we are trying to modify the same file 2x in a given action.

As it sounds like we are creating 2 "AtomicFile" objects for the
pack-names file, which is a bit iffy.

Anyway, as this patch gets you going, I'm fine with merging it.

BB:approve

I would just like to mention that the behavior you are seeing is
indicative of a logical bug. When we update a branch, we should only
have to write the last-revision file one time, similarly for auto-pack.

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

iEYEARECAAYFAklGaoQACgkQJdeBCYSNAAPt9gCeOGjY3pAynTAwidLwLsQ8kTQE
qboAn2c4HsI1B6nYNNuzTV8DpGE6Cp7S
=Dy73
-----END PGP SIGNATURE-----