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

Previous Next

Full log

View this message in rfc822 format

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 5291 <at> debbugs.gnu.org
Subject: 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.

Previous Next

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