5:08 p.m.
> Since I'm usually using several mail clients (from phone,
old mutt,
> mutt-kz) it happens quite often that mutt complains.
>
> rename: No such file or directory (errno = 2)
>
> and the only thing I can do about it is to kill whole mutt. What I
> believe is happening is that if I view unread mail, mutt remembers that
> it has to move the mail once it leaves current inbox. But before that,
> someone else touches the mail (probably moving the message from 'new'
> directory to 'cur'. After that mutt-kz can't find the original file and
> complains with the error message.
I think this is a problem with mutt-kz not syncing the notmuch database
as it updates the maildir flags for the email. I have noticed this
while using emacs-notmuch, notmuch cli, and mutt-kz.
Now consider the following scenario. Mutt sees new mail in a maildir,
then you read it. Now until the next notmuch sync (say with `notmuch
new' from a cron job or OfflineIMAP hook) notmuch thinks the file is
<maildir>/new/<some_name>,N. Whereas mutt has renamed it to
<maildir>/cur/<some_name>,S! This can happen everytime mutt updates a
maildir flag (IOW renames a message file). IMO, this is an inherrent
issue with the maildir format. So you will see this out-of-sync
behaviour when mutt flags an email as "old", read, or adds the replied
flag.
Right, that's also what I think is happening. Although when I try to
provocate the change deliberately, I'm not successful.
I find this behaviour quite inconvenient at times and planned to take
a
look at it. But then both lack of time, and lack of understanding of
mutt internals have been in the way :-p.
> This seems to be problem in the mutt maildir handling rather than in the
> notmuch addon, still I wonder if you saw that or even better have some
> plans on tackling that :)
I thought one possible solution might be introducing a hook to what ever
function that does the file renaming when maildir flags are updated.
I'm not sure how one can introduce a hook though. Another option would
be to add a inotify watch on the maildir currently mutt is viewing. And
follow-up on any inotify events.
That seems to be complicated and no matter what you do you will IMO just
decrease the likehood of such issue. You can't stop it completely, there
will always be a window when you can get two concurrent MUAs out of
sync. What I would like to try is to make mutt ignore any local changes
to the message when it has been changed underneath it. Just accept the
new state which has been force upon it.
in mh.c we have
static int maildir_sync_message (CONTEXT * ctx, int msgno)
{
...
if (rename (oldpath, fullpath) != 0)
{
mutt_perror ("rename");
return (-1);
}
}
what I believe happens is that rename fails, maildir_sync_message
returns -1, but mutt still remembers that it's supposed to rename the
file so it tries again next time you update the mailbox. Instead it
should forget the rename what was supposed to be written to disk, and
move to write any other outstanding changes. Then it should re-read
whole mailbox to get in sync with real state of emails.
But that's problem of mh.c so I believe mutt discussion alias is more
suited for this.
I wanted to know whether I'm the only one struggling at this, and I'm
glad I'm not (well, sort of :) ).
Hopefully I understood your question correctly and my comments make
sense to you.
Yes, definitely.
Thank you
--
Vlad