At 4:10 PM +0200 1/30/03, Spiros Ioannou wrote:
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.
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.
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.
This may cause mail to be bounced on some systems if the local
delivery agent is unable to lock the spool in some amount of time.
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
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Look Bruce, the bat signal!!!
