On 01 Dec 2015, at 12:30, Fredrik Roubert fredrik@roubert.name wrote:
Hello!
I run Debian jessie and have an issue with the interaction between Dovecot (2.2.13), Mutt (1.5.23) and the Android Gmail (5.8.105868218) IMAP client, when using Maildir:
I use Dovecot LMTP for local delivery into Maildir and access these files both through Dovecot IMAP from the Android Gmail IMAP client and also directly through the filesystem by running Mutt locally on the mail server.
When a new mail arrives, Dovecot LMTP will add a new file in Maildir/new and also update the Dovecot index cache. If I then open Mutt and just delete this new message, then Mutt will just delete this file from Maildir/new and the Dovecot index cache will be out-of-sync.
(For testing, Mutt can be cut out of the equation entirely by instead just running "rm Maildir/new/*" from the command line to mimic what Mutt does when deleting a new message, but I mention the use of Mutt here to show why this is a real use-case for me.)
If I after this open the Gmail app and pull down the message index to refresh from the Dovecot IMAP server, it'll get the cached version of the index, in which the new message is still present (but only the headers, no body will be loaded and the app will show no body snippet). Pulling down the message index again to force a second refresh will cause the new/deleted message to disappear again.
This seems to be caused by Dovecot not looking at the Maildir/new timestamp to determine whether the index cache is up-to-date, but instead only looking at the Maildir/cur timestamp.
Dovecot does check Maildir/new timestamp, but it'll only perform a "partial sync" then, which means it adds any newly found mails but it doesn't delete any mails because it can't be sure that they weren't moved to cur/. One simple fix for this would be to scan cur/ also whenever new/ changes, but that would unnecessarily make the performance worse for most people. Another fix would be to remember that the mail was in new/ and when cur's timestamp hadn't changed and the mail wasn't in new/ anymore it would be removed from index. But this would require remembering that the mail is in new/, which isn't currently done and adding it would probably cause extra disk writes.
So I don't really see a way of fixing this in any nice way.