On Tue, 2006-02-07 at 10:13 +0200, Tom Alsberg wrote:
Furthermore: If the last message seen from within Thunderbird was not yet read, and the problem occurs (new mail arrives that is not seen), this last message will then seem corrupted from Thunderbird the next message in the mailbox.
- it will contain at the end some garbage filling, and then part of
This is while the mailbox itself is completely valid, has no such garbage in it, and the messages are validly separated by an empty line and a valid "From " line. Perhaps this means there's some race-condition bug in the mbox reading/index syncing code? That's the code I least understand as of now...
Attached is an example of one such last message saved from Thunderbird after new mail arrived that was not seen. The filler characters are bytes of 0x80, and then the next message from "n-Path: " is present.
They're actually 0x00 inside the mbox file, but Dovecot just translates them to 0x80 since IMAP doesn't allow sending 0x00 characters.
Now, these 0x00 characters are added to mbox file when it's rewriting the headers and it figures out that it needs more space. So it first grows the file by writing 0x00 characters to the end of the file. Then it starts moving message data towards the end of file.
So you mean that this corruption is only seen by Thunderbird, and it won't stay in the mbox file itself? In that case it means that mbox locking isn't working properly, ie. a Dovecot process is reading the mbox while another Dovecot process is modifying it. I don't remember having tested mbox_read_locks=dotlock, but I'd have thought it would have worked..