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

[John Arbash Meinel]

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

Eli Zaretskii wrote:
>> From: Robert Collins <robertc at robertcollins.net>
>> Cc: bazaar at lists.canonical.com
>> Date: Tue, 05 Jan 2010 08:51:11 +1100
>>
>>> 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?
>> No, its not safe to read that file concurrently; I created a proof of
>> concept change that writes single files and permits status to succeedd
>> while commit is working. Its mentioned in the list a while back - search
>> for 'dirstate'.
> 
> If it's unsafe, then why does the problem not happen on GNU/Linux?
> AFAIU, there "bzr status" actually succeeds in reading that file even
> though it is locked, right?

Not in my experience. Running "bzr commit" and holding it in the editor,
and then running 'bzr status' or 'bzr diff' fails on Linux, too. I don't
know how Emacs works into the mix.

> 
>>> 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.
>> Can emacs be told to ignore changes to those files?
> 
> Not sure what you mean by that.  Emacs runs "bzr status" as part of
> saving the file with the commit message.  Emacs will do that for every
> file operation on any file within a directory controlled by some VCS
> it supports.  So the fact that bzr_log.FOO is changed or not is not
> the issue here.
> 
> Perhaps you mean to tell Emacs not to consider bzr_log.* files as
> versioned files.  In that case, I probably could do that, but on what
> grounds?  Telling it to just ignore any file named bzr_log.* would be
> dangerous: this is just a normal file name.  I could legitimately have
> a bzr_log.cpp file in some project, couldn't I?  And the fact that I
> edit it by request from emacsclient is also not a reason good enough:
> as you may imagine, I use emacsclient for many other similar
> situations in use-cases that have nothing to do with bzr.
> 
> That's why I said that having these files under $TMPDIR would be a
> good workaround -- then all these complications simply don't arise.
> 
> Am I missing something?
> 
> 

If you want to give it a try, this patch should do:
=== modified file 'bzrlib/msgeditor.py'
- --- bzrlib/msgeditor.py 2009-03-23 14:59:43 +0000
+++ bzrlib/msgeditor.py 2010-01-05 04:24:02 +0000
@@ -215,7 +215,7 @@
     """
     import tempfile
     tmp_fileno, msgfilename = tempfile.mkstemp(prefix='bzr_log.',
- -                                               dir='.',
+    #                                           dir='.',
                                                text=True)
     msgfilename = osutils.basename(msgfilename)
     msgfile = os.fdopen(tmp_fileno, 'w')

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

iEYEARECAAYFAktCvxwACgkQJdeBCYSNAAM7UACfSqbOZdkV3BhpbOmDQT6C943d
lRwAnj24PoOHvuwFHPLWuam0Zqxxl88K
=n3ZS
-----END PGP SIGNATURE-----