Re: RMAIL file locking problem?

[Evil Boris <evilborisnet@netscape.net>]

Richard Stallman <rms@gnu.org> 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?