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

[Eli Zaretskii]

> 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?

> > 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?