I see this problem very very rarely (usually when I have more one running mutts that modify the same virtual folder).
Maybe it would be possible to improve nm_sync() to read the message path from notmuch DB before it call mh_sync_mailbox_message(). Now the code blindly follows cached path (from nm_header_get_fullpath()).
As I saw the issue quite a lot lately, I tried to create a simple workaround.
--- a/mh.c +++ b/mh.c @@ -1721,8 +1721,11 @@ static int maildir_sync_message (CONTEXT * ctx, int msgno)
if (rename (oldpath, fullpath) != 0) { - mutt_perror ("rename"); - return (-1); + struct stat stat_s; + if (errno != 2 || stat (fullpath, &stat_s) != 0) { + mutt_perror ("rename"); + return (-1); + } } mutt_str_replace (&h->path, partpath); }
Even if we would read the mail file path from notmuch DB beore calling mh_sync_mailbox_message(), we would have to check whether we still need to call rename(2) or not. So in the situation when I know that my source file disapeared and the destination file is there, I blindly believe that the mails are the same. That's not the best solution out there, but I think that for me it will work perfectly.