From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Evil Boris Newsgroups: gmane.emacs.devel Subject: Re: RMAIL file locking problem? Date: Sat, 30 Apr 2005 16:05:38 -0400 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1114963493 5465 80.91.229.2 (1 May 2005 16:04:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 1 May 2005 16:04:53 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 01 18:04:50 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DSGvk-0005m9-2K for ged-emacs-devel@m.gmane.org; Sun, 01 May 2005 18:04:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DSH02-0003PH-FN for ged-emacs-devel@m.gmane.org; Sun, 01 May 2005 12:08:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DSGt0-0000F3-QU for emacs-devel@gnu.org; Sun, 01 May 2005 12:01:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DSGsy-0000Br-EP for emacs-devel@gnu.org; Sun, 01 May 2005 12:01:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DSGsi-0007z0-8B for emacs-devel@gnu.org; Sun, 01 May 2005 12:01:20 -0400 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1DSGsB-0007Pq-Pj for emacs-devel@gnu.org; Sun, 01 May 2005 12:00:47 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by mx20.gnu.org with esmtp (Exim 4.34) id 1DRyHy-0002ys-Jj for emacs-devel@gnu.org; Sat, 30 Apr 2005 16:10:10 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DRy80-0001eF-7b for emacs-devel@gnu.org; Sat, 30 Apr 2005 21:59:52 +0200 Original-Received: from 207-38-193-43.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com ([207.38.193.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Apr 2005 21:59:52 +0200 Original-Received: from evilborisnet by 207-38-193-43.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Apr 2005 21:59:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 72 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 207-38-193-43.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (windows-nt) Cancel-Lock: sha1:z9hmxgvFNR3dXuTa2KWp8GO6cBE= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:36530 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36530 Richard Stallman writes: > As far as I can tell, it is the following code: > > (if file-name > (rmail-insert-inbox-text files nil) > (setq delete-files (rmail-insert-inbox-text files t))) > > Ok, it seems natural that this would lock the current buffer. > It is trying to insert something. > > On my machine the locking trouble seems to happen when there is no new > mail. My understanding is that RMAIL reads in the contents of the > (empty!) mailbox (by the way, would it make sense to check for 0 > length and just skip the rest of jumping through hoops in this > case---no locking, no inserting of zero bytes, no testing for having > inserted zero bytes?) > > It seems strange that insert-file-contents would leave the buffer > locked if it does not really change the buffer. That could be a bug > in insert-file-contents: that it handles the zero-size case wrong. I may have found the problem. I leave the rest of my blabberings (the note I was editing before I discovered this) at the end, just in case it gives any further clues... As Richard has suggested, the problem may be in insert-file-contents. I was very reluctant to believe it, but now I am almost certain it is true, as I have repeatedly observed insert-file-contents called from rmail-insert-inbox-text, returning 0 as the number of bytes read, with the effect of leaving the underlying buffer (visiting ~/RMAIL in this case) locked. Can anyone confirm this, or give me some hints of how to indentify the circumstances when it happens? Thanks in advance, --Boris ========================= I am not very good at C-level debugging Emacs (nor Lisp-level, for that matter). I have been able somewhat reliably (but no very predictably, as in "I cannot tell how we get there") get Emacs into a state where there is no new mail, ~/RMAIL is unlocked, I type "g", and after checking the mail ~/RMAIL is locked. No message is "unseen". (I can force a removal of the lock by making ~/RMAIL explicitly modified by "t" "t" and the "s"aving. After that, the lock disappears. It reappears in the next "g".) Any hints at what to look for? I tried stepping through most of rmail-get-new-mail, but it does an excruciating number of file-name-rewriting and other odd operations. Or could one check the C code for "insert-file-contents"? Does it mark the buffer modified if 0 bytes were read. (BTW I looked at the C code there and it seems to say that it is not safe to ask the file descriptor for file size [eg if /proc file system] so my earlier suggestion of checking the file size of the mailbox before trying to insert its contents might not make as much sense I thought...) In short, I seem to be able to get Emacs somewhat predictable into a strange state. What data do I need to collect to try and figure out what's going on? --Boris PS. BTW, I did notice that on non-empty mboxes for some reason (before saving modified ~/RMAIL after the mailbox has been read in), the mailbox is locked twice. I first thought it very odd. Then I realize the first lock was in rmail-insert-inbox-text (when new stuff is inserted) and the second was in save-buffer, after Babyl-ifying the new data. The first seems to happen for empty mailbox too. Or does it?