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.
--
Vlad