[Resent to list - originally sent from a non-subscribed address]
On Tue, Jun 29, 2004 at 03:07:27PM -0500, Ladar Levison wrote:
> Howdy Qpopper List --
>
> I have a question that stems from my desire to integrate a Webmail
> system with my already up and running Qpopper 4.0.5 installation.
>
> Basically my concern is in regards to the Webmail system, and Qpopper
> cooperating nicely if both access the mbox file at the same time. I want
> to make sure someone doesn't log in through the webmail system, and
> Qpopper at the same time. Based on my reading of the source code
> documentation, Qpopper locks the Mailbox, then copies it to a temporary
> file. For the sake of this e-mail, I assume that temporary file is :
> /var/mail/.user.pop, (though I could be wrong). Qpopper then releases
> the lock on the Mailbox, and uses the .pop file for the session. When
> the session is over, the .pop file is copied back into the Mailbox.
>
> Is this correct? I have tried scanning the /proc/locks file for active
> locks, and I can't seem to find any. Perhaps because the files are
> copied, and released so quickly.
I'll be fairly brief about this because I'm busy with other things,
but I've looked into qpopper locking strategy extensively in the past.
This is all off-the-cuff from memory.
The normal method of locking the user's prime mailbox file (= mail
spool, = mbox) is the existence of the "dot-lock" file. That's the
mbox filename with ".lock" appended to it. This is respected by most
MTA's LDAs (local delivery agents), and qpopper uses it. IIRC, qpopper
uses an flock type lock not on the mailbox but on the mbox.lock file,
once it has created it.
qpopper uses the .pop session to lock against itself, and only
against itself.
qpopper locks the mailbox with the dot-lock file only while it is
moving the mail out of the file - not for the duration of the pop
session - and then again when it is restoring the mail to the file.
IMPORTANT NOTE: If you are running qpopper in "server mode", popper
assumes that the only way the file can be altered between these two
points is for mail to be *appended* to the file by the MTA; i.e. that
no shell mail client and no other mail program will alter the mailbox
other than via *appending*. In this case it will assume it can safely
handle a bunch of special cases to highly optimize the update of the
mailbox at the end of the POP session (successful or unsuccessful.) If
this assumption proves wrong - e.g. due to the webmail program - and
qpopper is using server mode, your mailboxes may end up horribly
corrupted from time to time.
> Now while the session is going on, qpopper uses flock() to lock the .pop
> file. That way if the session doesn't end normally, the lock still
> exists until the timeout period is over (120 seconds).
> I presently use --keep-temp-drop, so every user does have a .pop file.
> Could I code my webmail client to lock the .pop file using flock, then
> flock the Mailbox file? Would this effectively keep the two from
> accessing the files at the same time?
If you lock the .pop first (and abort on failure to get the lock)
then you will have successfully locked popper out, and vice-versa.
That part's good. If you want to use server mode, you must hold this
lock until you are completely done with any possible updates to the
mbox file.
> What if I just flock'ed the mbox file? The problem I see with that
> scenario is when someone is using pop, they might have all the active
> messages in the temp file, and there would be nothing for webmail system
> to read.
If you flock the mbox file (or the dot-lock file) you will lock
against POP, and are also locking against mail delivery. No mail will
be delivered while the dot-lock exists.
However, if you don't "stroke" the timestamp on the dot-lock
regularly, the MTA will typically assume it is a stale lock after about
5 minutes (300 seconds) and forcibly remove it. If you are still
accessing the mail file read/write at *that* point, much hilarity may
ensue.
The general strategy to be safe and efficient is: lock and access the
mbox; read it; unlock and let go of it while you do stuff; lock and
access it again when you need to update it, assuming that anything or
nothing may have happened to it in between; and repeat.
NOTE ALSO: the dot-lock behavior above *is* dependent on your MTA. The
above behavior is historical, based on old sendmail, but has been
replicated by many LDAs for historical reasons, as it's critical for
compatibility and interoperability. It's also incredibly poorly
documented and poorly understood. You should try to confirm that your
configuration is using it, before relying on it.
BTW, if you run UW-IMAPD, it locks against the mail spool using the
dot-lock scheme, but also has its own completely different locking
schema. I had patches to make qpopper safely interoperate with it, but
they weren't completely portable and have never been committed to the
qpopper mainline due to lack of time on my part.
As I said, this is all off-the-cuff from memory, so it's possible
I've misremembered something. I hope Randy or others can correct me if
so. I don't have a definite recommendation for you at the moment,
other than the general strategies I describe above.
This may not look brief, but believe me - this *is* the brief
version!
-- Clifton
--
Clifton Royston -- [EMAIL PROTECTED]
Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed? Did you ever walk with ten cats on your head?
Did you ever milk this kind of cow? Well we can do it. We know how.
If you never did, you should. These things are fun, and fun is good.
-- Dr. Seuss
