On Feb 22, 2008, at 11:26 AM, mikkel@euro123.dk wrote: Do you mean that you can see a situation with QUIT or EXPUNGE command when maildir's contents don't match maildirsize file? Or if you mean only setting the deleted flags, that's normal then because nothing really gets deleted yet anyway.
The delay wasn't long enough for me to physically test if the quota was our of sync meanwhile. My estimate is 5-10 seconds and it could be the system waiting for I/O or something. I just figured that maybe this was due to grouping of the transactions and thought that if so, then maybe it was possible that this code could fail in some situations.
This may be the cause of the issue since some users in a production environment will always break the connection (loss of internet connectivity, the client program crashing or just generally badly behaving e-mail clients).
For POP3 maybe, but they'd probably get duplicate messages downloaded then too, unless the client is smart with UIDLs.
I can see your point. If your coding does'n not allow for situations where dovecot gets interrupted in between doing the actual delete and update the maildirsize then I have no idea what happens. I just figured that maybe there was a week spot somewhere that could break in certain situations (like NFS locking troubles or something) :)
With IMAP could it be just that users have marked messages deleted and their client hides them, but the messages are never expunged? Or that the messages have been moved to Trash mailbox..
When I "du" the user's storage I can see that there is a lot less data than maildirsize claims (so this isn't due to hidden mails or mails in Trash).
Apparently the large majority of users have no problems whatsoever while e few specific users experience this every two weeks on average (when they finally reach the upper quota limit and report the error). The solution for now is to remove the file maildirsize so the quota will be recounted.
The way this happens it seems to me that it's not just a random NFS locking error but actually a bug somewhere and that some users manage to always trigger the bug (which seems to be triggered sometimes when pop3 is used) while others do not. But it's pretty difficult to get close to the cause.
Does Dovecot actually check whether updating the maildirsize is successful or not after calling the operations (e.g. what happens if the code is unable to read from or write to maildirsize)?
Regards, Mikkel