Hi Timo,
I've made some further research on this issue (Dovecot was upgraded to the latest release in the meantime but, unsurprisingly, to no avail) and here's what I've found so far.
On 09/02/2014 10:42, Gilles Chauvin wrote:
dsync(user2): Error: read(/zfspool/clone_srv_attachments/ad/0c/ad0cef35cc6f0b2dae2197c4ff2b61a2bd58070d-9e8345192ccbf352c210000044c1c7e7-6efa5f2e522db350ed3d000094b229f9-15470[base64:18 b/l]) failed: Stream is larger than expected (194476 > 194475, eof=1) dsync(user2): Error: copy: i_stream_read() failed: Invalid argument dsync(user2): Panic: file mail-index-transaction-update.c: line 19 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
The original mail got an attachment which is base64 encoded on 72 cols. The last 3 lines are:
MAAxADMAIAAyADAAOgAwADEAOgA1ADQADQAKAGwAJwB1AHQAaQBsAGkAcwBhAHQAZQB1AHIA IABkAGUAIABsAG8AZwBpAG4AOgAgAGsAZQBsAGUAbQBhAHIAaQAgAGEAIADpAHQA6QAgAGMA cgDpAOkAIABsAGUAIAAyADEALwAwADMALwAyADAAMQAzACAAMgAwADoAMAAyADoAMAA0AA0ACgA=
For no good reason, the last line lacks a CR before the final "CgA=" part.
I guess this is where Dovecot yells about the "stream larger than expected" because when it reencodes the attachment, it does it correctly by adding a proper CR before "CgA=" hence the one byte difference (tested using the "base64" command line tool).
During my tests, each time dsync failed with this particular error, the same pattern applied (malformed base64 last line).
Looks like a pretty hard problem to solve but, for now, it prevents us from restoring a mailbox.
Regards, Gilles