"bzr status" fails due to lock by "bzr commit"

[Eli Zaretskii]

I have Emacs configured as the editor for bzr commit messages, as
described on http://wiki.bazaar.canonical.com/EmacsTips.  This works
very well, but on MS-Windows, when I save the commit message after
editing it, Emacs bitches at me:

  vc-do-command: Running bzr status bzr_log.uuzkwa...FAILED (status 3)

After some digging, I found out that what happens is this:

  . I run "bzr ci" from the shell prompt, which launches emacsclient
    to let me edit the commit message.  For that purpose, bzr puts the
    list of files to be committed on a temporary file bzr_log.FOO in
    the directory where I run "bzr ci", and submits that file to
    emacsclient.  Note that this directory is almost always a
    versioned directory, i.e. it is inside a tree of some bzr branch.

  . The file with the commit message pops up in Emacs, where I edit
    it.  When I'm done editing, I save the bzr_log.FOO file.

  . Emacs then runs "bzr status bzr_log.FOO" as a side effect of
    saving it, because the file is inside a versioned directory.
    (Emacs does that because it has built-in support for versioned
    files; e.g. it shows their status on the mode line.  So for each
    file in a versioned directory, Emacs wants to know if the file
    itself is versioned.)  This "bzr status" command fails with status
    3.

Here's the full diagnostics I find in my .bzr.log file after each of
these incidents:

  Sun 2010-01-03 19:28:03 +0200
  0.109  bzr arguments: [u'status', u'-Derror', u'bzr_log.ytsmkq']
  0.140  looking for plugins in C:/Documents and Settings/Zaretzky/Application Data/bazaar/2.0/plugins
  0.140  looking for plugins in D:/usr/Bazaar/plugins
  0.468  encoding stdout as sys.stdin encoding 'cp862'
  0.578  opening working tree 'D:/gnu/bzr/emacs/test'
  0.593  Traceback (most recent call last):
    File "bzrlib\commands.pyo", line 842, in exception_to_return_code
    File "bzrlib\commands.pyo", line 1037, in run_bzr
    File "bzrlib\commands.pyo", line 654, in run_argv_aliases
    File "bzrlib\commands.pyo", line 1052, in ignore_pipe
    File "bzrlib\builtins.pyo", line 306, in run
    File "bzrlib\builtins.pyo", line 74, in tree_files
    File "bzrlib\builtins.pyo", line 177, in internal_tree_files
    File "bzrlib\builtins.pyo", line 194, in safe_relpath_files
    File "bzrlib\views.pyo", line 112, in lookup_view
    File "bzrlib\views.pyo", line 178, in _load_view_info
    File "bzrlib\workingtree_4.pyo", line 578, in lock_read
    File "bzrlib\dirstate.pyo", line 3039, in lock_read
    File "bzrlib\lock.pyo", line 372, in __init__
    File "bzrlib\lock.pyo", line 357, in _open
  LockContention: Could not acquire lock "D:/gnu/bzr/emacs/test/.bzr/checkout/dirstate": (32, 'CreateFileW', 'The process cannot access the file because it is being used by another process.')

My analysis of this is that "bzr ci" locked dirstate, and then "bzr
status" tries to lock it again, and fails.

This does not happen on GNU/Linux, only on Windows.

Is it possible to share the lock between "commit" and "status"?  If
so, can bzr be fixed to not cause such sharing violations on Windows?
(I'm guessing it's a matter of using the right flags in CreateFileW
API, but maybe it's not that simple.)  Should I submit a bug report?

Failing that, a workaround would be to have an option to tell bzr to
create these bzr_log.* files in a temporary directory, like $TMPDIR on
Unix or $TEMP on Windows.  Then Emacs won't run "bzr status" and won't
trigger this error.

TIA