On 19/02/13 09:42, Timo Sirainen wrote:
On 19.2.2013, at 11.39, Rob Redpath rob.redpath@heartinternet.co.uk wrote:
BTW. http://dovecot.org/tools/maildir-size-fix.pl has been updated to work with compressed files also, making maildir-size-check.sh obsolete.
I had a quick look myself - it looks like it would be! Obviously I can't leave my production system in a state where mail can't be accessed by some of its users - so what would your advice be to work around this?
I think my options are:-
- Modify and recompile dovecot so that the affected sub is a no-op and guarantee that filenames will always reflect the uncompressed size of the message through other means OR
- Ensure that the sub never gets called. What condition is it that Dovecot encounters that triggers it to rename a file? Just run the maildir-size-fix.pl to your existing maildirs and you should have no problems in future?
Sadly, that doesn't seem to work. In a normal case where I see this issue, running maildir-size-fix.pl (with -a -c -f -r -v options) identifies and renames lots of files, but then accessing the mailbox causes dovecot to rename them back to the incorrect values.
One thing I've noticed during testing this is that, in my doveadm fetch output for an affected mailbox, the same UID appears to be processed over and over before Dovecot moves on. In the example I happen to have on screen, this line appears 13 times in the output, each with with a larger value to the right of the <
doveadm(user@example.com): Error: Maildir filename has wrong S value, renamed the file from /var/spool/virtual_mail/user_example.com_d/.INBOX.folder/cur/1308038406.M274176P16579.mail.example.net,S=11919:2,S to /var/spool/virtual_mail/user_example.com_d/.INBOX.folder/cur/1308038406.M274176P16579.mail.example.net,S=11919:2,S doveadm(user@example.com): Error: Corrupted index cache file /var/spool/virtual_mail/user_example.com_d/.INBOX.eBay/dovecot.index.cache: Broken physical size for mail UID 99