[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:
> John Arbash Meinel wrote:
>> Adrian Wilkins wrote:
>>
>>> 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.
>>
> 
> This seems to agree with the behaviour I was seeing. The logs attached
> to one of the bug comments show the file activity for both failing and
> successful cases, and for the post-patch case, which should show the
> multiple use of AtomicFile for last-revision file. The logs are for
> 
> bzr branch <network branch one> <new branch in same no-trees repo>
> 
>> 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.
>>
> 
> On further examination it would seem that `bzr branch` uses *three*
> instances of AtomicFile for last-revision. I can examine more cases if
> you would like.
> 
> This is for
> 
> bzr branch y:\repository_old\tools y:\repository\tools
> 
>  ; where y:\ is a drive letter mapped to a CIFS share.
> 
> PoSh #> cat Filemon_success_randchars.LOG | % { $_.Split("`t")[4] } |
> select-string "repository\\tools\\.bzr\\branch\\last-revision" | sort |
> unique
> 
> Y:\repository\tools\.bzr\branch\last-revision
> Y:\repository\tools\.bzr\branch\last-revision.5212.040912-xp.82hqvtjkgm.tmp
> Y:\repository\tools\.bzr\branch\last-revision.5212.040912-xp.baxxu6xmd3.tmp
> Y:\repository\tools\.bzr\branch\last-revision.5212.040912-xp.bjcjyohcyb.tmp
> Y:\repository\tools\.bzr\branch\last-revision?
> 

So at "bzr branch" time I can certainly imagine 2 times (one time is
just creating the file on disk, and the other time is populating it with
the new data.)

I don't know where the third time would come from. And certainly you can
argue against the creating a file with uninteresting data to start with.

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

iEYEARECAAYFAklGdSIACgkQJdeBCYSNAAPeZACgyh56OEX7GWYAs9GO9eVzcoUh
rigAn0Z1quKluZEzha3M/5X+Epd/zcKI
=z8yZ
-----END PGP SIGNATURE-----