Richard Stallman <[EMAIL PROTECTED]> writes:
> I don't know how to debug this remotely, but if you run
> under GDB, you can put a breakpoint at lock_file and see
> when and where it locks the file. Using the xbacktrace
> GDB command at that point would give us a lot of info
> about the reason, probably enough to figure out what's
> happening.
I played with it a bit. Emacs locks many files, so this gets quite
tedious. As far as I can tell, this always happens here:
==========
(gdb) xbacktrace
"insert-file-contents"
"rmail-insert-inbox-text"
"rmail-get-new-mail"
"call-interactively"
(gdb) cont
==========
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)))
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?)
Any ideas of what else I can check? It seems like one way the
lockfile appears (but not consistently!?!?!?) when I type "g" to get
new mail, while there isn't any in the mail box.
Any and all ideas welcome.
--Boris
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
