Timo Sirainen <tss at 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. 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. -- Heiko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20160629/7cc1a641/attachment.sig>
On 29 Jun 2016, at 01:13, Heiko Schlittermann <hs at schlittermann.de> wrote:> > Timo Sirainen <tss at 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.
Timo Sirainen <tss at iki.fi> (Mi 29 Jun 2016 00:20:05 CEST): ?> > 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?Yes, dsync(heiko): Warning: Deleting mailbox 'Trash': UID=18290 already exists locally for a different mail: highest than remote's UIDs (remote UIDNEXT=19588) This happend during a sync to an empty local destination The source (cyrus) is an active/passive cluster, the IP I'm connecting to should be on the same machine for the time the syncronisation runs. But I'll check this. Thank you for responding? It give me the hope that it *should* work. (Meanwhile I'm writing 'yet-another-imap2imap' sync tool, but using dsync would be the better choice, definitivly) Best regards from Dresden/Germany Viele Gr??e aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20160629/aea81a5d/attachment.sig>