On 29 Jun 2016, at 01:13, Heiko Schlittermann hs@schlittermann.de wrote:
Timo Sirainen tss@iki.fi (Mi 29 Jun 2016 00:00:11 CEST): …
b) UID=16 suddenly appeared on Cyrus side even though it wasn't there earlier. This isn't allowed by IMAP standard. It's still strange if Cyrus is doing that. It's generally a pretty well behaving IMAP server. What version is it?
- OK srvlx Cyrus IMAP4 v2.2.12 server ready
Maybe, did you read my previous post with a similar subject? There I had an empty local destination and some nasty effects too.
There was another mail with "highest than remote's UIDs" error. Do you mean that one? I don't see others. That's also kind of strange. Dovecot had seen mails that suddenly no longer existed on Cyrus side. It's as if you're syncing to two different Cyrus servers that are somewhat out of sync themselves. Is that possible?
In case it helps:
mail_location = maildir:~:INBOX=/volumes/dovecot/inbox/%2.256Nn/%n:INDEX=/volumes/dovecot/cache/%2.256Nn/%n
which leads to
/volumes/dovecot/{cache,home,inbox}/<hash>/<user>
is used for the maildir storage. As I'm writing this, I'm not sure, if I really purged the /var/vmail/cache/ hierarchy. But home/ and inbox/ where clean as a baby.
The storage is imported via NFS. But the other backends (we're using a director/backend setup) are switched off, to really be sure the we don't have concurrent access.
An out-of-date index with Maildir shouldn't really matter since it should get automatically updated.