Comment 3 for bug 304023

I think the "3000" is indicative of the process being kept alive to service a bzr-eclipse instance, although I've seen it occur at the command line also.

The checkout is directly bound to y:\ via the CIFS / SMB / Windows network share method.

A race is possible but the repository is only in use by ~5 people, and I get reports of this problem at approximately the intervals you might expect from autopacking ; anecdotally it seems far too frequent to be racing.

I would suspect opportunistic locking more strongly if we hadn't had a group policy update aimed at switching oplocks off, which I've verified manually by reading the registry on at least one affected machine.

Since all the checkouts are heavy, does the client even need to read pack-names on the server? The commonest usage scenario here is that each user is typically the sole user on a given branch, so they shouldn't need to be reading packs from the server very often, except when comitting - it should be possible to verify that there are no new revisions just by reading indices and revision lists (? is this true - I don't know enough to answer off the top of my head but it would seem to be intuitively sound).

Does the code move the original pack-names file before writing over it during a commit transaction? Would that work?