[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RMAIL file locking problem?
From: |
Evil Boris |
Subject: |
Re: RMAIL file locking problem? |
Date: |
Sat, 30 Apr 2005 16:05:38 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (windows-nt) |
Richard Stallman <address@hidden> 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?
- Re: RMAIL file locking problem?,
Evil Boris <=
- Re: RMAIL file locking problem?, Richard Stallman, 2005/05/01
- Re: RMAIL file locking problem?, Evil Boris, 2005/05/09
- Re: RMAIL file locking problem?, Richard Stallman, 2005/05/11
- Re: RMAIL file locking problem?, Evil Boris, 2005/05/11
- Re: RMAIL file locking problem?, Richard Stallman, 2005/05/12
- Re: RMAIL file locking problem?, Evil Boris, 2005/05/13
- Re: RMAIL file locking problem?, Richard Stallman, 2005/05/14
- Re: RMAIL file locking problem?, Evil Boris, 2005/05/14