Hi,
I wonder if you would consider including the following workaround to maildir
folder handling. The problem is that maildir stores various flags set on a mail
in a 'info' suffix like
mymail.txt:2FRS
Unsetting 'FLAGGED' for example means renaming to
mymail.txt:2RS
If you change any flags in mutt, it tries to rename the file appropriately. If
it does not succeed, mutt prints a 'rename' error and becomes more or less
unusable. You can't leave current maildir because you can't sync the changes to
a mail. For me, this happens quite frequently - two MUAs read the same mail,
first marks it as read (removes the unread flag) and the second gets stuck. I
wrote a little patch which adds not so nice workaround for this issue. Even
though it's not the best solution under the sun, it works pretty well. I wonder
if there are any chances of including this workaround to mutt official source
tree.
The diff is from mutt-kz (notmuch based mutt), but if there would be interest
I'm happy to rework it to vanilla mutt sources.
diff --git a/mh.c b/mh.c
index 6c476a7..a98bfda 100644
--- a/mh.c
+++ b/mh.c
@@ -1721,8 +1721,22 @@ static int maildir_sync_message (CONTEXT * ctx, int
msgno)
if (rename (oldpath, fullpath) != 0)
{
- mutt_perror ("rename");
- return (-1);
+ struct stat stat_s;
+ /*
+ * Renaming the message file failed. This can happen for a variety of
+ * reasons, but probably because more than one MUAs access the same MH
+ * folder. Generally it would be difficult to merge two parallel
+ * operations like flagging a message and marking it as unread, but the
+ * most common scenario seems to be that two MUAs just open the mail and
+ * try to unset the 'unread' flag. For such scenario we have workaround
+ * here. If the original file does not exist, but the file we want to
+ * rename it to does, we accept the renamed file as if we would rename it
+ * ourselves.
+ */
+ if (errno != EACCESS || stat (fullpath, &stat_s) != 0) {
+ mutt_perror ("rename");
+ return (-1);
+ }
}
mutt_str_replace (&h->path, partpath);
}
Thank you
--
Vlad
