Bug 599686 – mail-client/mutt-1.7.1-r3 duplicates messages when save-message with multiple tagged messages

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description S. Gilles 2016-11-13 21:54:41 UTC]

When tagging more than one message, then invoking save-message (via ‘;s’), mutt will create duplicate messages in the destination folder.  This has only been observed when working with local maildirs.

This has not been observed with mutt built from upstream, or when USE="vanilla" is set.

Reproducible: Always

Steps to Reproduce:
1. Download attached Mail-mwe.tar.xz.  It is a maildir containing two folders, a and b. Inside a are two messages.
2. Launch mutt with configuration file .muttrc-mwe (after editing to point to wherever Mail-mwe was extracted to).
3. Tag both messages with ‘t’
4. Move to folder b with ‘;s=b<Enter><Enter>’
5. Change to folder b with ‘c=b<Enter><Enter>’

Actual Results:  
There are four messages in folder b.

Expected Results:  
There should be two messages in folder b.

This does not happen if only one message is tagged, or if the messages are moved without tagging at all (using ‘s’ instead of ‘;s’).

This does not happen when USE="vanilla" is set.

    $ eix -I mutt
    [I] mail-client/mutt
         Available versions:  *1.5.23-r7 1.5.24-r2 (~)1.7.1-r3 {berkdb crypt debug doc gdbm gnutls gpg idn imap kerberos libressl mbox nls nntp notmuch pop qdbm sasl selinux sidebar slang smime smtp ssl tokyocabinet vanilla}
         Installed versions:  1.7.1-r3(08:08:43 PM 11/05/2016)(berkdb crypt gdbm gpg imap libressl nls sasl sidebar smtp ssl -debug -doc -gnutls -idn -kerberos -mbox -nntp -notmuch -pop -qdbm -selinux -slang -smime -tokyocabinet -vanilla)
         Homepage:            http://www.mutt.org/
         Description:         A small but very powerful text-based mail client

[Comment 1 S. Gilles 2016-11-13 21:55:09 UTC]

Created attachment 453258 [details]
.muttrc-mwe

[Comment 2 S. Gilles 2016-11-13 21:55:32 UTC]

Created attachment 453260 [details]
Mail-mwe

[Comment 3 Fabian Groffen 2016-11-19 20:30:13 UTC]

@Richard: does this ring a bell to you?

[Comment 4 Richard Russon 2016-11-19 21:09:53 UTC]

Hi Fabian,

Yes, this was the result of a bad merge on my part.

This fixes the problem:
https://github.com/neomutt/neomutt/commit/57c97aa

Rich

[Comment 5 Fabian Groffen 2016-11-20 09:57:34 UTC]

Darn you're a hero.  I should've searched some more, sorry for the bother.

[Comment 6 Fabian Groffen 2016-11-20 11:15:22 UTC]

Hah, you got me searching here for a while.  Richard's patch doesn't apply to us, since we're almost the same as upstream.  I didn't take too serious notice of the -r3, when you use -r4, the problem isn't there.  I can't find where it was introduced or fixed, but since it is fixed in -r4, I'll close this bug as fixed. :)

Thanks