On 19/02/13 09:42, Timo Sirainen wrote:
On 19.2.2013, at 11.39, Rob Redpath <[email protected]> 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([email protected]): 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([email protected]): 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
