On May 25, 2008, at 10:09 PM, Jason Forester wrote:
Maildir++ quota recalculation works like:Go through all files and sum up their sizes. Keep track of the highestdirectory mtime. Once everything is calculated, again go through all directories and find the highest mtime. If the highest mtime had increased, something had changed, so delete maildirsize file. So could it be simply that the recalculation is slow enough that the maildir changes during it and causes the file to be deleted? Another possibility is that some error happens, but then Dovecot should have logged something.I'm not seeing anything in my logs. It's certainly possible that multiple mails are delivered during a recalculation. I'm not quite sure I understand the mtime explanation above, are you saying that if dovecot thinks that the maildirsize file is inaccurate it deletes it and goes on?
Pretty much, yes. If any mailbox's new/ or cur/ directory changes in some way (flag changes also cause this..) during recalculation, the result is just discarded.
Do you keep your quota limits stored only in the maildirsize file? If not, having the files deleted shouldn't affect functionality, but of course the performance is worse.Basically yes, we have many users with different quotas and as such we cannot use a single quota in the config file.
That's a bug in v1.0 actually, it shouldn't be deleting the file if it can't be regenerated. v1.1 doesn't delete it and just hopes it gets eventually recalculated and fixed.
So, it sounds like I'm the only person who has encountered this problem? If it's really just a consequence of the maildir changing, wouldn't it be more common?
I think there are two issues:1) Your recalculation is probably quite slow, assuming you don't have the S=sizes in filenames. deliver adds these to new mails, but it doesn't help for old ones.
2) Most people specify the limits in Dovecot's userdb, so this isn't an issue.
What userdb do you use?
PGP.sig
Description: This is a digitally signed message part
