© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Curiouser and curiouser .....
I rebranched most of the branches to a new repo to remove some cruft.
On my machine the following succeeds.
rm -r -for y:\repository\tools
bzr branch y:\repository_
On the other machine it fails with an ERR 17 (errno.EEXIST) on the target "last-revision" file, reliably.
I checked the oplocks settings and both machines are identical in that regard.
Comparing a filesystem trace from the two machines reveals that the name collision is not occuring on the actual last-revision file, but the temp filename used in AtomicFile. The name that AtomicFile uses is invariant - and it looks like on the machine that fails, one end of the client/server equation is convinced that this file still exists when a second AtomicFile creates it, even though it is renamed successfully in both traces.
row 459 in log - last-revision atomic file is renamed
row 629 in log - one machine succeeds at creating new atomic file, one machine fails with "NAME COLLISION"
I've added rand_chars(10) to the filename that AtomicFile generates, which seems to have no ill effects, and I'll test this change on the affected machine tomorrow to see if it cures the problem with no ill effects (the user concerned has gone home).