GNU bug report logs - #5291
23.1.91; "bzr status" FAILED

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5291 in the body.
You can then email your comments to 5291 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.91; "bzr status" FAILED
Date: Sat, 02 Jan 2010 19:43:18 +0200

I have set up Emacs to be the EDITOR for bzr via emacsclient (yes, I'm
invoking bzr from the command line).  That works, but every time I
commit a file to upstream, Emacs bitches with the following message in
*Messages*:

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


In GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600)
 of 2009-12-31 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  flyspell-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
C-u - 7 C-x <tab> <up> <up> <right> <delete> <delete> 
<down> <down> <delete> C-x C-s C-x # C-x b * M e s 
s <tab> <return> C-a C-SPC C-e M-w C-x b <return> <C-prior> 
<C-prior> <C-prior> <C-prior> <C-prior> <C-prior> <C-prior> 
<C-prior> <C-prior> C-x k <return> C-x b I N B <tab> 
<return> <M-home> C-x k <return> C-x b <M-up> <up> 
<down> <down> <up> <up> <up> <M-right> - <tab> <return> 
<M-end> <help-echo> <help-echo> <help-echo> m C-y C-x 
C-x <delete> <delete> <delete> 4 6 6 8 <down> <switch-frame> 
<switch-frame> <right> R e : S-SPC C-y <right> <down> 
<down> <down> T h a n k s , SPC I S-SPC m a d e SPC 
t h e SPC a u t o - g e n e r a t e d SPC d o c SPC 
s t r i n g <C-left> <C-left> <C-left> <C-left> <left> 
SPC l i n e s SPC i n SPC t h e SPC t e m p l a t e 
SPC u s e d SPC f o r <M-right> s SPC s <backspace> 
<backspace> <up> <C-right> <C-right> <C-right> <C-right> 
SPC s h o r t e r M-q <down> . <down> <return> C-c 
C-s <help-echo> <help-echo> <help-echo> <switch-frame> 
m e m a c s - d e v e l @ g n u . o r g <down> <C-end> 
<return> C-y M-y M-y <up> <up> <up> <up> <up> " b z 
r SPC s t a t u s " S-SPC F A I L E D <down> <down> 
<down> <down> <return> <up> <up> <up> <up> <up> <up> 
<right> <right> <right> <right> <delete> <delete> <delete> 
<delete> <delete> <delete> <delete> <delete> <delete> 
<delete> <delete> M-! C-g M-~ <switch-frame> <switch-frame> 
M-x r e p o r t - e m <tab> <return>

Recent messages:
Wrote d:/gnu/bzr/emacs/trunk/bzr_log.uuzkwa
vc-do-command: Running bzr status bzr_log.uuzkwa...FAILED (status 3)
Mark set [3 times]
Sending...
Added to d:/usr/eli/rmail/SENT.MAIL
Sending...done
Mark set [2 times]
Auto-saving...done
Quit
Modification-flag cleared

Load-path shadows:
None found.

Features:
(shadow emacsbug rmailmm vc-dispatcher add-log tar-mode mule-util
ebuff-menu electric vc-bzr help-mode view rmailout dabbrev
multi-isearch auth-source message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums nnheader gnus-util netrc mm-util
mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util
hashcash smtpmail mailalias mailabbrev sendmail conf-mode newcomment
ld-script sh-script executable dired-x dired-aux dired tcl generic
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn
nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc
xmltok sgml-mode arc-mode archive-mode jka-compr make-mode cc-mode
cc-fonts cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
regexp-opt gud comint ring parse-time vc-cvs org-wl org-w3m org-vm
org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html
org-exp org-exp-blocks org-agenda org-info org-gnus org-bibtex
org-bbdb org byte-opt bytecomp byte-compile advice help-fns
advice-preload org-footnote org-src org-list org-faces org-compat
org-macs time-date noutline outline easy-mmode info easymenu flyspell
ispell rmailsum rmail mail-utils desktop server filecache saveplace
generic-x paren battery time tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

Message #8 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5291 <at> debbugs.gnu.org
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sat, 2 Jan 2010 12:47:00 -0800 (PST)

Eli Zaretskii <eliz <at> gnu.org> writes:

  > I have set up Emacs to be the EDITOR for bzr via emacsclient (yes, I'm
  > invoking bzr from the command line).  That works, but every time I
  > commit a file to upstream, Emacs bitches with the following message in
  > *Messages*:
  > 
  >   vc-do-command: Running bzr status bzr_log.uuzkwa...FAILED (status 3)

Do you get a backtrace if you set debug-on-error?

Message #11 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 5291 <at> debbugs.gnu.org
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sat, 02 Jan 2010 23:40:33 +0200

> Date: Sat, 2 Jan 2010 12:47:00 -0800 (PST)
> From: Dan Nicolaescu <dann <at> ics.uci.edu>
> Cc: 5291 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>   > I have set up Emacs to be the EDITOR for bzr via emacsclient (yes, I'm
>   > invoking bzr from the command line).  That works, but every time I
>   > commit a file to upstream, Emacs bitches with the following message in
>   > *Messages*:
>   > 
>   >   vc-do-command: Running bzr status bzr_log.uuzkwa...FAILED (status 3)
> 
> Do you get a backtrace if you set debug-on-error?

Yes, see below.

AFAICT, it shouldn't even try to run "bzr status" on this file, since
it's a temporary file used by bzr for the commit message.  But if it
somehow must run "bzr status", then it shouldn't signal an error when
it predictably fails.  But maybe I'm missing something.

Debugger entered--Lisp error: (error "Running bzr status bzr_log.ahvp69...FAILED (status 3)")
  signal(error ("Running bzr status bzr_log.ahvp69...FAILED (status 3)"))
  error("Running %s...FAILED (%s)" "bzr status bzr_log.ahvp69" "status 3")
  vc-do-command(t 0 "bzr" "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69" "status")
  apply(vc-do-command t 0 "bzr" "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69" "status" nil)
  vc-bzr-command("status" t 0 "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-bzr-status("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-bzr-state("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-bzr-state-heuristic("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-bzr-registered("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  apply(vc-bzr-registered "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-call-backend(Bzr registered "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  #[(b) "\302\303	#\205\304	\305#\205\306\307\310\"\207" [b file vc-call-backend registered vc-file-setprop vc-backend throw found t] 4](Bzr)
  mapc(#[(b) "\302\303	#\205\304	\305#\205\306\307\310\"\207" [b file vc-call-backend registered vc-file-setprop vc-backend throw found t] 4] (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch))
  byte-code("\303\304\"\305\306	\203	\307=\203\n\202	\nB\"\210)\310\304\307#\210\311\207" [file backend vc-handled-backends vc-file-getprop vc-backend mapc #[(b) "\302\303	#\205\304	\305#\205\306\307\310\"\207" [b file vc-call-backend registered vc-file-setprop vc-backend throw found t] 4] none vc-file-setprop nil] 4)
  vc-registered("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-backend("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  vc-after-save()
  basic-save-buffer()
  save-buffer(1)
  call-interactively(save-buffer nil nil)

Message #14 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 5291 <at> debbugs.gnu.org
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sat, 2 Jan 2010 22:56:24 +0100

Looks like the "binary chars" in this message made it hard to read, at
least on gmail.

On Sat, Jan 2, 2010 at 10:40 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Sat, 2 Jan 2010 12:47:00 -0800 (PST) > From: Dan Nicolaescu <dann <at> ics.uci.edu> > Cc: 5291 <at> debbugs.gnu.org > Eli Zaretskii <eliz <at> gnu.org> writes: >   > I have set up Emacs to be the EDITOR for bzr via emacsclient (yes, I'm >   > invoking bzr from the command line).  That works, but every time I >   > commit a file to upstream, Emacs bitches with the following message in >   > *Messages*: >   >  >   >   vc-do-command: Running bzr status bzr_log.uuzkwa...FAILED (status 3) > Do you get a backtrace if you set debug-on-error? Yes, see below. AFAICT, it shouldn't even try to run "bzr status" on this file, since it's a temporary file used by bzr for the commit message.  But if it somehow must run "bzr status", then it shouldn't signal an error when it predictably fails.  But maybe I'm missing something. Debugger entered--Lisp error: (error "Running bzr status bzr_log.ahvp69...FAILED (status 3)")   signal(error ("Running bzr status ...

Message #17 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5291 <at> debbugs.gnu.org
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sat, 2 Jan 2010 14:17:30 -0800 (PST)

Eli Zaretskii <eliz <at> gnu.org> writes:

  > > Date: Sat, 2 Jan 2010 12:47:00 -0800 (PST)
  > > From: Dan Nicolaescu <dann <at> ics.uci.edu>
  > > Cc: 5291 <at> debbugs.gnu.org
  > > 
  > > Eli Zaretskii <eliz <at> gnu.org> writes:
  > > 
  > >   > I have set up Emacs to be the EDITOR for bzr via emacsclient (yes, I'm
  > >   > invoking bzr from the command line).  That works, but every time I
  > >   > commit a file to upstream, Emacs bitches with the following message in
  > >   > *Messages*:
  > >   > 
  > >   >   vc-do-command: Running bzr status bzr_log.uuzkwa...FAILED (status 3)
  > > 
  > > Do you get a backtrace if you set debug-on-error?
  > 
  > Yes, see below.
  > 
  > AFAICT, it shouldn't even try to run "bzr status" on this file, since
  > it's a temporary file used by bzr for the commit message.  But if it
  > somehow must run "bzr status", then it shouldn't signal an error when
  > it predictably fails.  But maybe I'm missing something.
  > 
  > Debugger entered--Lisp error: (error "Running bzr status bzr_log.ahvp69...FAILED (status 3)")
  >   signal(error ("Running bzr status bzr_log.ahvp69...FAILED (status 3)"))
  >   error("Running %s...FAILED (%s)" "bzr status bzr_log.ahvp69" "status 3")
  >   vc-do-command(t 0 "bzr" "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69" "status")
  >   apply(vc-do-command t 0 "bzr" "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69" "status" nil)
  >   vc-bzr-command("status" t 0 "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-bzr-status("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-bzr-state("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-bzr-state-heuristic("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-bzr-registered("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   apply(vc-bzr-registered "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-call-backend(Bzr registered "d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   #[(b) "\302\303	#\205\304	\305#\205\306\307\310\"\207" [b file vc-call-backend registered vc-file-setprop vc-backend throw found t] 4](Bzr)
  >   mapc(#[(b) "\302\303	#\205\304	\305#\205\306\307\310\"\207" [b file vc-call-backend registered vc-file-setprop vc-backend throw found t] 4] (RCS CVS SVN SCCS Bzr Git Hg Mtn Arch))
  >   byte-code("\303\304\"\305\306	\203	\307=\203\n\202	\nB\"\210)\310\304\307#\210\311\207" [file backend vc-handled-backends vc-file-getprop vc-backend mapc #[(b) "\302\303	#\205\304	\305#\205\306\307\310\"\207" [b file vc-call-backend registered vc-file-setprop vc-backend throw found t] 4] none vc-file-setprop nil] 4)
  >   vc-registered("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-backend("d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69")
  >   vc-after-save()
  >   basic-save-buffer()
  >   save-buffer(1)
  >   call-interactively(save-buffer nil nil)

Strange.
What exactly creates the d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69 file?
Is your TEMP set to d:/gnu/bzr/emacs/trunk/ ?

I think that if you change:
                   (vc-bzr-command "status" t 0 file)
to:
                   (vc-bzr-command "status" t 3 file)
in vc-bzr-status
it should work, but I am not 100% sure that's TRTD.

Message #20 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 5291 <at> debbugs.gnu.org
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sun, 03 Jan 2010 06:09:58 +0200

> Date: Sat, 2 Jan 2010 14:17:30 -0800 (PST)
> From: Dan Nicolaescu <dann <at> ics.uci.edu>
> Cc: 5291 <at> debbugs.gnu.org
> 
> What exactly creates the d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69 file?

"bzr commit" does.  This file is where it puts the list of files to be
committed, then submits it to $EDITOR (in my case, emacsclient), and
expects me to insert the commit message there.  After "bzr commit" is
done (i.e., the changes committed), this file is deleted by bzr.

> Is your TEMP set to d:/gnu/bzr/emacs/trunk/ ?

No.  AFAIU, bzr creates these temporary files in the directory where
you run "bzr commit".  I see these files created in the current
directory on GNU/Linux as well, although I will have to check if the
same problem happens there as well as on Windows.

> I think that if you change:
>                    (vc-bzr-command "status" t 0 file)
> to:
>                    (vc-bzr-command "status" t 3 file)
> in vc-bzr-status
> it should work, but I am not 100% sure that's TRTD.

OK, I will look into this when I have a chance.  Thanks.

Do you (or someone else) know where can I find the documentation of
status code returned by bzr?

Message #23 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 5291 <at> debbugs.gnu.org
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sun, 03 Jan 2010 20:39:06 +0200

> Date: Sun, 03 Jan 2010 06:09:58 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 5291 <at> debbugs.gnu.org
> 
> > Date: Sat, 2 Jan 2010 14:17:30 -0800 (PST)
> > From: Dan Nicolaescu <dann <at> ics.uci.edu>
> > Cc: 5291 <at> debbugs.gnu.org
> > 
> > What exactly creates the d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69 file?
> 
> "bzr commit" does.  This file is where it puts the list of files to be
> committed, then submits it to $EDITOR (in my case, emacsclient), and
> expects me to insert the commit message there.  After "bzr commit" is
> done (i.e., the changes committed), this file is deleted by bzr.
> 
> > Is your TEMP set to d:/gnu/bzr/emacs/trunk/ ?
> 
> No.  AFAIU, bzr creates these temporary files in the directory where
> you run "bzr commit".  I see these files created in the current
> directory on GNU/Linux as well, although I will have to check if the
> same problem happens there as well as on Windows.
> 
> > I think that if you change:
> >                    (vc-bzr-command "status" t 0 file)
> > to:
> >                    (vc-bzr-command "status" t 3 file)
> > in vc-bzr-status
> > it should work, but I am not 100% sure that's TRTD.
> 
> OK, I will look into this when I have a chance.  Thanks.

I found the problem.  It seems to be Windows-specific.  (I cannot
reproduce it on GNU/Linux, but I have a slightly different version of
Bazaar there, so it could be bzr-version specific as well.  Still, the
nature of the problem (see below) makes it a safe bet that it exists
only on Windows.)

The detailed reason for the failure is found in the .bzr.log file:

  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.')

What happens is evidently this:

  . I run "bzr ci", which locks dirstate and launches emacsclient to
    edit the commit message that it puts on a temporary file
    bzr_log.FOO in the directory where I run "bzr ci".

  . 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 run "bzr status bzr_log.FOO" as a side effect of C-x
    C-s, because the file is inside a versioned directory.  This "bzr
    status" tries to lock dirstate again, which fails, because Windows
    fails the CreateFileW system call due to sharing issues.

I could probably submit a bug for Bazaar, but they would probably say
that Emacs is to blame as well as Bazaar: it is Emacs who invokes the
second instance of bzr while the first is still running.

It would be nice if I could tell Bazaar to put those bzr_log.FOO files
under $TMPDIR, but there doesn't seem to be a way of doing that.
Anyone?

Any ideas for how best to resolve this?

> Do you (or someone else) know where can I find the documentation of
> status code returned by bzr?

To answer my own question: exit status 3 means that there was some
fatal exception or error in running the command.  When that happens,
bzr writes a full traceback to .bzr.log file, so one should look there
for that info.

Message #26 received at 5291 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5291 <at> debbugs.gnu.org
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sun, 3 Jan 2010 12:10:06 -0800 (PST)

Eli Zaretskii <eliz <at> gnu.org> writes:

  > > Date: Sun, 03 Jan 2010 06:09:58 +0200
  > > From: Eli Zaretskii <eliz <at> gnu.org>
  > > Cc: 5291 <at> debbugs.gnu.org
  > > 
  > > > Date: Sat, 2 Jan 2010 14:17:30 -0800 (PST)
  > > > From: Dan Nicolaescu <dann <at> ics.uci.edu>
  > > > Cc: 5291 <at> debbugs.gnu.org
  > > > 
  > > > What exactly creates the d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69 file?
  > > 
  > > "bzr commit" does.  This file is where it puts the list of files to be
  > > committed, then submits it to $EDITOR (in my case, emacsclient), and
  > > expects me to insert the commit message there.  After "bzr commit" is
  > > done (i.e., the changes committed), this file is deleted by bzr.
  > > 
  > > > Is your TEMP set to d:/gnu/bzr/emacs/trunk/ ?
  > > 
  > > No.  AFAIU, bzr creates these temporary files in the directory where
  > > you run "bzr commit".  I see these files created in the current
  > > directory on GNU/Linux as well, although I will have to check if the
  > > same problem happens there as well as on Windows.
  > > 
  > > > I think that if you change:
  > > >                    (vc-bzr-command "status" t 0 file)
  > > > to:
  > > >                    (vc-bzr-command "status" t 3 file)
  > > > in vc-bzr-status
  > > > it should work, but I am not 100% sure that's TRTD.
  > > 
  > > OK, I will look into this when I have a chance.  Thanks.
  > 
  > I found the problem.  It seems to be Windows-specific.  (I cannot
  > reproduce it on GNU/Linux, but I have a slightly different version of
  > Bazaar there, so it could be bzr-version specific as well.  Still, the
  > nature of the problem (see below) makes it a safe bet that it exists
  > only on Windows.)
  > 
  > The detailed reason for the failure is found in the .bzr.log file:
  > 
  >   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.')
  > 
  > What happens is evidently this:
  > 
  >   . I run "bzr ci", which locks dirstate and launches emacsclient to
  >     edit the commit message that it puts on a temporary file
  >     bzr_log.FOO in the directory where I run "bzr ci".
  > 
  >   . 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 run "bzr status bzr_log.FOO" as a side effect of C-x
  >     C-s, because the file is inside a versioned directory.  This "bzr
  >     status" tries to lock dirstate again, which fails, because Windows
  >     fails the CreateFileW system call due to sharing issues.
  > 
  > I could probably submit a bug for Bazaar, but they would probably say
  > that Emacs is to blame as well as Bazaar: it is Emacs who invokes the
  > second instance of bzr while the first is still running.

It seems that this is actually a combination of bzr "features": putting
a temporary file in a versioned directory plus the fact that "bzr status" blocks 
when a commit is in progress (i.e. a read lock blocks when a write lock
is on).

  > It would be nice if I could tell Bazaar to put those bzr_log.FOO files
  > under $TMPDIR, but there doesn't seem to be a way of doing that.
  > Anyone?
  > 
  > Any ideas for how best to resolve this?

Not sure we want to do something in emacs about this, it looks like bzr
needs fixing.

Message #31 received at 5291-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 5291-done <at> debbugs.gnu.org
Subject: Re: bug#5291: 23.1.91; "bzr status" FAILED
Date: Sat, 09 Jan 2010 10:05:44 +0200

> Date: Sun, 3 Jan 2010 12:10:06 -0800 (PST)
> From: Dan Nicolaescu <dann <at> ics.uci.edu>
> Cc: 5291 <at> debbugs.gnu.org
> 
> It seems that this is actually a combination of bzr "features": putting
> a temporary file in a versioned directory plus the fact that "bzr status" blocks 
> when a commit is in progress (i.e. a read lock blocks when a write lock
> is on).
> 
>   > It would be nice if I could tell Bazaar to put those bzr_log.FOO files
>   > under $TMPDIR, but there doesn't seem to be a way of doing that.
>   > Anyone?
>   > 
>   > Any ideas for how best to resolve this?
> 
> Not sure we want to do something in emacs about this, it looks like bzr
> needs fixing.

First, it turns out this happens on GNU/Linux as well, at least if one
invokes "bzr status" while "bzr ci" is waiting for emacsclient.

The solution, suggested by John Arbash Meinel on the Bazaar mailing
list, is to patch msgeditor.py, a bzr module, as shown in the patch
below.  This will cause Bazaar to create the bzr_log.* files in the
system temporary directory, so Emacs will not try to run "bzr status"
on it.

If you are on Windows, and installed Bazaar with a standalone
installer, then you will need to download from the Bazaar site the
sources of Bazaar that correspond to your installed version.  Then
locate library.zip, remove from it bzrlib/mzgeditor.pyo, and add the
patched bzrlib/mzgeditor.py.

If you are on Unix or GNU system, you will need to talk to your
sysadmin about replacing msgeditor with a patched version.


--- bzrlib/msgeditor.py~	2010-01-08 23:36:47.257578300 +0200
+++ bzrlib/msgeditor.py	2010-01-09 09:51:45.472750000 +0200
@@ -215,8 +215,9 @@
     """
     import tempfile
     tmp_fileno, msgfilename = tempfile.mkstemp(prefix='bzr_log.',
+#                                              dir='.',
                                                text=True)
-    msgfilename = osutils.basename(msgfilename)
+#   msgfilename = osutils.basename(msgfilename)
     msgfile = os.fdopen(tmp_fileno, 'w')
     try:
         if start_message is not None:

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.