I have a patch for this, see here:
http://www.mail-archive.com/qpopper@lists.pensive.org/msg05281.html
and here:
http://image.ntua.gr/~sivann/test/popper-ntua.tar.gz
The patch keeps the spool lock active while the mail is in the temp. New mail
waits for the spool to unlock. I can't understand why this is not default/option.
-S
Edward Chase wrote:
The snippet below from a previous email gives me the impression that it
could help me with with an issue I'm having here with users quotas.
My current scenario...
* /var/mail holds the users mailboxes (and is it's own filesystem).
* /var/spool/poptemp is qpopper's scratch area, I'm assuming this is the
"temp-drop".
* My users have a quota on /var/mail.
* Assume a user is at his limit then check email.
* /var/mail/user is moved to /var/spool/poptemp/.user.pop by qpopper
(filesytem quota on /var/mail is now zero)
* sendmail now moves email from delivery queue into /var/mail/user
* qpopper is done and attempts to move /var/spool/poptemp/.user.pop back to
/var/mail/user, but can't because the new mail that is in /var/mail/user
plus the old mail in /var/spool/poptemp/.user.pop is too much for the quota
on /var/mail. Yes, the user is leaving mail on server (grrrr...)
* now the user has mail data in two places and the thing just keeps getting
worse as the user checking email will allow the file in the temp-drop to
grow. (Now I'm thinking to myself, why didn't I put user quotas on /var?)
Assuming you follow that... Should I be able to fix this problem by putting
the temp-drop in the /var/mail filesystem and use the -fast-io switch?
-----Original Message-----
From: Randall Gellens [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006 3:13 PM
To: Hugh Sasse; Gregory Hicks
Cc: qpopper@lists.pensive.org
Subject: Re: Large spool mboxes => slow?
[snip]
You might also want to think about using the fast-io option, which
renames the temp-drop to the spool instead of copying it. This only
works if the temp drop and spool are on the same filesystem.
[snip]
