On Fri, Jan 31, 2003 at 12:01:07PM -0800, Randall Gellens wrote: > What should be happening is that at the end of the session, Qpopper > locks the spool, copies anything in it (by definition new mail that > arrived during the session) to the temp spool, truncates the spool. > then tries to copy the temp spool to the spool. During this final > copy, it gets an error because the user's quota is exceeded. Qpopper > logs this and exits. At this point the spool should be empty and all > the mail should be in the temp spool, ready to be recovered.
Yes, I read the code and you are correct, temp file remains and the spool is re-truncated if user quota is exceeded, but: 1. If the user checks mail with another protocol his mail is invisible because it resides at the temp (we also have webmail through imap). 2. When new mail arrives, it is appended to the truncated spool, while user mail resides at the temp because of the "overquota copying temp to spool" error of the previous session. When the user tries to check mail again, the same error applies and his new spool mail is appended to the previous temp, so all new mail is accumulated in the temp file rendering all quota mechanism useless. Imagine now deleting by hand (and by user request) the large mail from a system with thousands of users. 3. When the user starts his mail client and his spool was left at the temp file due to the above overquota problem, his client re-gets all the mail in the temp file along with the new in the spool. But the mail in the temp file was already downloaded to the client and old mail appears now duplicate and new mail once normal. The next time he checks, mail is duplicated again , old-old messages exist now 3 times, old 2 times and new just appended from spool 1 time. And so on. We assume he has "leave messages on server" 4. As for mail.local returning the mail in case of a locked spool this is wrong, the mail should stay in the queue. If some systems have problem with this then they should get a better sendmail/mail.local or avoid using quotas, because the spool gets locked one way or another-and for a long time, especially when mailboxes are large (>100MB) and disk activity is high, so these systems will loose mail anyway. For the above reasons I hold to my previous assumption that the locking logic is erroneous. At least it creates a lot of problems for us, and an option for an alternative locking logic would be much appreciated since tampering with the source is time-consuming. I await your replys/advices Thank you. Spiros Ioannou e-mail:[EMAIL PROTECTED] --------------------------------------- Image Video & Multimedia Systems Lab. Department of Electrical & Computer Eng. National Technical University of Athens
