On 29 Jun 2016, at 01:13, Heiko Schlittermann <h...@schlittermann.de> wrote:
>
> Timo Sirainen <t...@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.
