From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.bugs Subject: bug#5291: 23.1.91; "bzr status" FAILED Date: Sun, 3 Jan 2010 12:10:06 -0800 (PST) Message-ID: <201001032010.o03KA611029754@godzilla.ics.uci.edu> References: <83d41se72h.fsf@gnu.org> <201001022047.o02Kl0iT010221@godzilla.ics.uci.edu> <837hs0dw32.fsf@gnu.org> <201001022217.o02MHUE3013455@godzilla.ics.uci.edu> <83637jesmh.fsf@gnu.org> <834on3dodx.fsf@gnu.org> Reply-To: Dan Nicolaescu , 5291@debbugs.gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262549950 31243 80.91.229.12 (3 Jan 2010 20:19:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 3 Jan 2010 20:19:10 +0000 (UTC) Cc: 5291@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 03 21:19:03 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NRWuj-0002vm-Jy for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Jan 2010 21:19:02 +0100 Original-Received: from localhost ([127.0.0.1]:33935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NRWuj-0008H2-WE for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Jan 2010 15:19:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NRWuV-0008AX-Ei for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2010 15:18:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NRWuQ-00088N-Dh for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2010 15:18:46 -0500 Original-Received: from [199.232.76.173] (port=41030 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NRWuQ-00088K-8E for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2010 15:18:42 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:6476) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NRWuQ-0002gS-3A for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2010 15:18:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NRWuM-0008Mo-4O for bug-gnu-emacs@gnu.org; Sun, 03 Jan 2010 15:18:38 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NRWn0-0001RN-HV; Sun, 03 Jan 2010 15:11:02 -0500 X-Loop: bug-gnu-emacs@gnu.org Mail-Followup-To: Dan Nicolaescu , 5291@debbugs.gnu.org Resent-From: Dan Nicolaescu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Jan 2010 20:11:02 +0000 Resent-Message-ID: Resent-Sender: bug-gnu-emacs@gnu.org X-Emacs-PR-Message: followup 5291 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 5291-submit@debbugs.gnu.org id=B5291.12625494235526 (code B ref 5291); Sun, 03 Jan 2010 20:11:02 +0000 Original-Received: (at 5291) by debbugs.gnu.org; 3 Jan 2010 20:10:23 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NRWmM-0001R5-U3 for submit@debbugs.gnu.org; Sun, 03 Jan 2010 15:10:23 -0500 Original-Received: from colin-baker-v0.ics.uci.edu ([128.195.1.153]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NRWmL-0001R0-3W for 5291@debbugs.gnu.org; Sun, 03 Jan 2010 15:10:21 -0500 Original-Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by colin-baker-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id o03KA6ex032559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jan 2010 12:10:06 -0800 Original-Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id o03KA611029754; Sun, 3 Jan 2010 12:10:06 -0800 (PST) In-Reply-To: <834on3dodx.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 Jan 2010 20:39:06 +0200") Original-Lines: 75 X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information X-ICS-MailScanner-ID: o03KA6ex032559 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.363, required 5, autolearn=disabled, ALL_TRUSTED -1.44, TW_BZ 0.08) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu X-Spam-Score: -2.7 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list X-Spam-Score: -2.7 (--) Resent-Date: Sun, 03 Jan 2010 15:11:02 -0500 X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:33900 Archived-At: Eli Zaretskii writes: > > Date: Sun, 03 Jan 2010 06:09:58 +0200 > > From: Eli Zaretskii > > Cc: 5291@debbugs.gnu.org > > > > > Date: Sat, 2 Jan 2010 14:17:30 -0800 (PST) > > > From: Dan Nicolaescu > > > Cc: 5291@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.