Windows file locking with bzr 2.2.3

[Martin (gzlist)]

On 24/02/2011, W. Trevor King <wking at drexel.edu> wrote:
>
> I see two possibilities:

Both of which may be right.

> 1) I'm calling cmd_add wrong.  Certainly a possibility, since the
> calling conventions have changed a few times over the past two years.

If you're only ever passing the cwd for 'file_ids_from' Don't Do That.
This change makes your test script work for me:

--- bzr-be-test.py
+++ bzr-be-test-works.py
@@ -23,7 +23,7 @@
     print 'add the file via Python'
     cmd = bzrlib.builtins.cmd_add()
     cmd.outf = sys.stdout
-    cmd.run([new_file], file_ids_from='.')
+    cmd.run([new_file])
     print 'success'
 finally:
     print 'cleanup test directory'

If it's sometimes meaningful and this was just the test script
simplifying things then see the following.

> 2) This is a Bazaar bug (possibly fixed in more recent versions?).

It's a Bazaar bug, can also do the same thing as your script on the
command line and run into the same problem:

    B:\>bzr init bzrbetest
    Created a standalone tree (format: 2a)

    B:\>cd bzrbetest

    B:\bzrbetest>bzr add --file-ids-from=.
    bzr: ERROR: Could not acquire lock
"B:/bzrbetest/.bzr/checkout/dirstate": (32, 'CreateFileW', 'The
process cannot access the file because it is being used by another
process.')

Basically, 'file-ids-from' is designed so you can pass a *different*
tree as the source for the path-id mappings. That tree is read-locked,
then the current tree to add stuff in is opened write-locked. As locks
on unix don't do anything half the time using the same tree twice
works there, but windows is stricter.

One option for a fix in bzrlib would be just to detect that situation
and only lock the tree once, or raise a user error. In your code,
omitting the parameter only if it's the current tree will work with
current bzrlib releases and in future when the bug is fixed.

Martin