Comment 2 for bug 587795

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

Andrew Bennetts wrote:
> Public bug reported:
>
> Originally reported at
> <https://bugs.launchpad.net/bzr/+bug/139253/comments/20>, by Bo Thorsen
> (~bo.thorsen):
>
> """
> I have been hit by this bug three times over the last month on Windows 7 64 bit with bzr 2.1.1 and python 2.6.5.
>
> The first two times were with a shared repository version 1.9, tomorrows
> problem was with version 2a.
>
> I have an automated build system running, which may have been killed
> during a bzr operation.
>
> I don't think this was the case with the others, but with this one I hit
> a lock on a branch that I had to remove with bzr break-lock, and after
> that, I get:
>
> C:\Users\bo\mp\mariadb>bzr branch lp:~maria-captains/maria/5.1-release 5.1-release
> bzr: ERROR (ignored): 'file:///C:/Users/bo/mp/mariadb/.bzr/repository/upload/ifyfp443v9nszroaal9x.pack'
> bzr: ERROR: File exists: u'C:/Users/bo/mp/mariadb/.bzr/repository/upload/ifyfp443v9nszroaal9x.pack': [Error 183] En fil,
> som allerede findes, kan ikke oprettes
>
> Sorry about the Danish translations. The error 183 says "A file, that
> already exists, can't be created".
>
> Maybe it's possible to reproduce the bug by checking out the repository
> multiple times and kill it each time - not ctrl-C it, but kill the
> process. And it might have to be on Windows.
>
> Deleting the file in .bzr/repository/upload doesn't help. It complains about a new file on each run.
> """
>
> This is pretty odd, as the filenames in the upload directory should be
> randomly chosen. Perhaps some pack_repo code is trying to create an
> already created file? It's also interesting that this doesn't seem to
> happen to all Windows users (otherwise we'd be inundated with reports
> about it), so perhaps there's some other factor involved, like a
> particular virus scanner?

Almost definitely this is caused by a crashing pull that managed to move
the content into .bzr/repository/packs but failed to add it to
.bzr/repository/pack-names

Unfortunately, the windows error only gives you 1 name, the source, when
what you actually care about is the collision on the destination.

I believe Martin just merged a patch to use a custom 'rename' that
raises an exception with both names (from and to), so that we can get
better error messages at least.

Some things to resolve/workaround the issue:

1) do a partial pull 'bzr pull -r -2'. This should create content that
is different than what you already pulled, and thus succeed the final
rename.

2) use 'bzr dump-btree [--raw] .bzr/repository/pack-names' and compare
the entries there to 'ls .bzr/repository/packs', you can remove any
files that aren't listed in pack-names.

I believe we have an open bug that if we get a collision in a pack
filename, what we would like to do is verify the content, and then just
use it.

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

iEYEARECAAYFAkwPuP8ACgkQJdeBCYSNAANcAwCgrMRVGT5L6Ol4aMmD2t2/UYiM
6okAnRQA24guX+Zakf9jplLzdI3yboUY
=PiuB
-----END PGP SIGNATURE-----