On 30 Jan 2016, at 10:04, Peer Heinlein <p.heinlein at
heinlein-support.de> wrote:>
>
> We're acutally using
>
> 2:2.2.21-1~auto+83
>
> and sometimes we have in our logfiles:
>
> Jan 30 08:50:14 mailimap01 dovecot: imap(username): Error:
>
unlink(/vmail/username/mdbox/mailboxes/foldername/dbox-Mails/dovecot.index.cache)
> failed: No such file or directory (in mail-cache.c:28)
>
> Jan 30 08:50:14 mailimap01 dovecot: imap(username): Error: Corrupted
> index cache file
> /vmail/username/mdbox/mailboxes/foldername/dbox-Mails/dovecot.index.cache:
> Broken MIME parts for mail UID 70
>
> The mail in this folder with uid 70 looks perfect and I'm able to fetch
> that mail without errors.
>
> I hope this is a self-healing error in the index file without real
> incident to the user. But I wonder how this Error can be happen.
It means that the MIME structure was written wrong to dovecot.index.cache file.
At the time it was attempted to be used, Dovecot realized that it can't be
right. It's difficult to say how or why this could happen though unless
there was some way to reproduce it.. Maybe if you copy the message from the user
and attempt to re-deliver it to a test user's INBOX and see if you can cause
it to break there? Also during the delivery Dovecot has to add
"mime.parts" to dovecot.index.cache. You can force that for example by
adding mail_always_cache_fields=mime.parts settings (and you can verify with
"doveadm dump /path/to/dbox-Mails/dovecot.index" that it shows the
mime.parts there after delivery). I think you can force Dovecot to detect the
broken MIME structure by running SEARCH TEXT hello on the folder.
Anyway, this is self-healing and potentially not even visible to user/client.