Description of problem: I use mutt for a Mail User Agent configured with nano as the editor for email messages. Normally when replying to messages in mutt, it saves the quoted message to be edited into a temporary file of the form "mutt-<hostname>-<uid>-<pid>-<n>" in the temporary directory, and then calls the configured editor on this file. The user is expected to save the edited message back to this same filename, which mutt then reads and uses for finishing the compose process, allowing the user to change header fields, add attachments, apply PGP, etc. before finally sending the message. However, when replying to some emails, mutt saves the quoted email to a filename that ends in <n>, but then does something to the message, perhaps dos/mac conversion, saves the message to a new filename that ends in <n+1>, and calls the editor on this new file. Unfortunately, after you are done editing the message, mutt expects the message to be in the original filename <n>, not <n+1>, so mutt displays a blank set of headers and no body for finishing the email compose process. I can find both the original "mutt-<hostname>-<uid>-<pid>-<n>" and converted "mutt-<hostname>-<uid>-<pid>-<n+1>" files in the temporary directory when this happens. As an aside, it seems that whenever mutt does this mysterious conversion/filename change and calls the editor on "mutt-<hostname>-<uid>-<pid>-<n+1>", nano detects the new file as "Mac format" and auto-converts the message. I have verified that it is not nano changing the filename though, it is definately mutt calling the editor with the new filename but expecting the original filename back. The end result is the user thinks "<editor> lost my email reply!" even though it isn't lost, just stored in a different temporary file where mutt can't find it, and it was mutt's fault for calling the editor on this different filename in the first place. Version-Release number of selected component (if applicable): mutt-1.5.18-2.fc9.i386 How reproducible: Always seems to happen for messages that nano considers "Converted from Mac format" after mutt fiddles with them, not sure which ones those are, but they definitely didn't come from a Mac. Steps to Reproduce: 1. Reply to a message in mutt 2. Notice the nano message "[ Read 54 lines (Converted from Mac format) ]" 3. Edit the reply and save. 4. Mutt shows no email headers and no body to finish the compose with. 5. Repeat the above steps, but this time save the edited result with a name that ends in <n-1> instead of <n>. Now Mutt finds the reply. Actual results: [ Read 54 lines (Converted from Mac format) ] Filename silently changed from e.g. mutt-foo-10002-4818-404 to mutt-foo-10002-4818-405. Editor called with the "-405" one, but if you manually save the file as "-404" it works fine. Expected results: Mutt should know which filename it called the editor with, and expect the edited message to come back in the same filename, not one with a decremented number.
Further investigation reveals that mutt isn't "converting" the message between the <n> and <n+1> versions. Even for replies that "work" correctly, the difference between the two temporary files is just the headers that mutt prepends to the reply. E.g., in replying to the bugzilla email this ticket generated, the differences are: --- mutt-foo-10002-5600-118 2008-12-11 18:41:50.000000000 -0500 +++ mutt-foo-10002-5600-119 2008-12-11 18:41:50.000000000 -0500 @@ -1,3 +1,11 @@ +From: Chuck Anderson <cra> +To: bugzilla +Cc: +Bcc: +Subject: Re: [Bug 476104] New: mutt "loses" email replies +Reply-To: +In-Reply-To: <bug-476104-1573.com> + On Thu, Dec 11, 2008 at 06:30:29PM -0500, bugzilla wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug. ..and this reply worked just fine So it is a mystery to me what exactly is triggering mutt to think the edited message should have been in <n> and not <n+1>, but when this happens, mutt "loses" the reply because it isn't properly formatted--all the headers are missing. Even worse, it seems that something is deleting the <n+1> temporary file, so you actually lose all your edits unless you are keen to notice the nano "Converted from Mac format" message and Ctrl-Z to suspend mutt and copy the temporary file to a backup. Or save the message to the original <n> filename.
Ok, at first I thought this was a mutt bug, but it seems to be a nano bug. First, switching to pico from the alpine package doesn't exhibit this behaviour at all. Second, calling nano with "-N" to disable automatic conversion also prevents the issue from occurring. I'm switching the component to nano.
Sorry, slightly lost. Can you summarise what nano is doing wrong? Is it changing the filename when it does the format conversion? Or was the filename a red herring, and it's the format conversion itself which causes the problem? If the latter -- if mutt is feeding messages with Mac line endings to the editor and expecting them to come back that way too -- then I'd probably argue that it's a mutt bug. It should be using standard unix line endings.
I'm not really sure myself. At first, I thought mutt was expecting the edited message to be in a different filename than it opened the editor with (only for some messages), because saving the edited message in the *original* filename caused mutt to work correctly. But if that was the only factor, changing the editor or editor arguments wouldn't make a difference, which it does. It seems that the editor is doing something strange to the file which mutt doesn't like, or zeroing out the file. I think I saw that the file became 0 length after nano edited it. I'll have to try to verify this.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.