Description of Problem: With the Milan-re0626.0 tree, I'm getting the message "Write failed! Saved partial mailbox to <path>" when attempting to purge a mailbox. Have actually had this happen on two different machines, but not really sure that it's a mutt issue at all, but figured that I would log it here. Version-Release number of selected component (if applicable): How Reproducible: Steps to Reproduce: 1. start up mutt 2. Save a message from one folder to another 3. Hit <shift><4> to sync the mailbox Actual Results: Expected Results: Additional Information:
NFS? Local files?
No, these are local files that I'm seeing this behavior on. Have a machine here at the desk if you would like to poke at it.
Take a look at: http://bugs.guug.de/db/12/1254.html (page linked from http://bugs.guug.de/db/pa/lmutt.html)
Making this a public bug so that people can comment on it.
Jakub, this seems related to the glibc version in use?
Right before this bug went public, I submitted it as bug number 68272. Here is what I had to say: The problem seems to be in the file mbox.c. Around line mbox.c:908, several checks are made to ensure the mailbox is sane: [...] if (fseek (ctx->fp, offset, SEEK_SET) != 0 || /* seek the append location */ /* do a sanity check to make sure the mailbox looks ok */ fgets (buf, sizeof (buf), ctx->fp) == NULL || (ctx->magic == M_MBOX && mutt_strncmp ("From ", buf, 5) != 0) || (ctx->magic == M_MMDF && mutt_strcmp (MMDF_SEP, buf) != 0) || (ctx->magic == M_KENDRA && mutt_strcmp (KENDRA_SEP, buf) != 0)) [...] The fgets in this check fails on my system. If I stick a perror in the code following the fgets, it prints "No such file or directory." Because this check fails, i is set to -1, causing the error message to be printed around line mbox.c:962. This "No such file or directory" error from fgets is strange. None of the other operations on ctx->fp fail, including the open operations. Could there be a bug in glibc? Probably not. I am having more trouble finding the source of this problem than I expected. I will update this bug report as I discover more. And later: I still have these problems if I downgrade the mutt rpm on my system from the limbo version (which has never worked) to the 7.3 version (which used to work with 7.3). This seems to support my theory that the problem is in a library (glibc?), not mutt.
This looks like glibc mmap stdio problem, debugging...
Oh yes, freopen ("...", "r+", f) on stdio mmap f is not doing the right thing, will have a patch soonish.
http://sources.redhat.com/ml/libc-hacker/2002-07/msg00012.html
*** Bug 68272 has been marked as a duplicate of this bug. ***
*** Bug 68915 has been marked as a duplicate of this bug. ***
Fixed in glibc-2.2.90-15.
Fix confirmed with Milan-re0724.nightly tree.
I have a similar problem with mutt and glibc-2.2.90-15 did not fix it. Basically, when mutt checks for new mail, it sometimes fails and prints "Mailbox was externally modified. Flags may be wrong.". It happens about 10% of the time (but the problem is deterministic). In mutt-1.4i the problem occurs at: mbox.c: /* * check to see if the content-length looks valid. we expect to * to see a valid message separator at this point in the stream */ if (fseek (ctx->fp, tmploc, SEEK_SET) != 0 || fgets (buf, sizeof (buf), ctx->fp) == NULL || mutt_strncmp ("From ", buf, 5) != 0) { In this boolean expression, fseeks works, but fgets fails with errno==2 (no such file or directory), which makes me thinks there is still a bug in glibc. I have tried several versions of mutt, and all of them reproduces the bug.
The problem is indeed fixed with glibc-2.2.5-37. Should I open a new bug report?
If you are seeing behavior different than described above, then yes, please open a separate bug and post details there.
Ok. So, see bug 70076 for this new problem.