Hello, I've already sent this to [EMAIL PROTECTED] a long time ago, but with no feedback.
Consider the following scenario for non-server mode: 1. a user (near his mail quota limit) opens a pop connection 2. popper locks his mail spool with Qmaillock (.lock file), copies his spool to a temporary file (outside the quota filesystem), truncates the spool and *unlocks* the spool. 3. While popper is running, the user gets new mail delivered to his spool and now total mail for this user exceeds his quota 4. When the user finishes getting his mail, the user's mail spool is locked again by qpopper and then the popper is trying to update the user's mailspool with non-deleted messages from the temp file but the user's quota is now exceeded. So popper dies with an error, leaving a possibly corrupted spool. So, I conclude the following: Qpopper should preserve the spool lock while it is running and not only while it is updating the spool to avoid such problems.If the spool stays locked the local delivery agent (like mail.local) will wait. Qmailunlock should be called only just before closing the TCP connection and should not be called after zeroing (or copying in case of server-mode) the mail spool. Puting the temp file inside the same filesystem with the spool doesn't solve anything, you just need the double quota. Running in server mode still solves nothing since a temp file is also created at sometime since the mailbox's Status flags need to be updated. I corrected this bug by modifying the qpopper source not to unlock the spool and calling Qtouchlock in intervals of 3 minutes. I have no problems till now. Any more ideas on this? Spiros Ioannou
