On Fri, Nov 30, 2001 at 03:48:18PM -0800, Randall Gellens wrote: > At 8:56 AM -1000 11/30/01, Clifton Royston wrote: > >Based on our past testing, and knowing that > >some customers leave multiple machines checking POP every few minutes, > >we're fairly sure that if somebody starts a webmail (or any other) IMAP > >session on one of those accounts, with qpopper running in server mode, > >their mailspool will be corrupted in minutes. > > Someone (and I apologize for forgetting who that was) suggested an > option for Qpopper to hold the spool lock for the duration of the > session. That might be a good way around this problem, assuming > IMAPD locks the spool.
It certainly does, or it would get horrendous corruption from mail delivery. I did find that in the archives and we discussed this as a different option for how to solve the problem. However... I have a gut feeling there could be problems which would result in the mail delivery system (local MTA) from long POP sessions holding the mail spool lock for too long and causing incoming mail to back up into the mail queue. From what I remember there may also be some threshold or age at which the mail program will typically decide the lock on the spool is "stale" and will force it. And I think this is only in the 5 or 10 minute range. (Don't quote me on this...) If someone can conclusively debunk my fears about those possible side-effects, we'd be very interested, as this would be a simpler change, I think. A third option we discussed was simply adding an independent mail session lock to both qpopper and imapd; it didn't seem like this was necessarily better than consulting the locking methods each is already using. (Unless one were going to try to add this to many daemons besides these two.) I could see one more option which would be distinctly better than this but which would involve major rewrites of large sections of qpopper - it would have to become smart enough to tell that the spool had been updated in some way other than via mail delivery appending to it, check for this condition at the end of a server mode session, and revert to something like its non-server-mode method of updating the mailbox by merging changes made from its own session back into whatever remains in the spool. That seems like a whole lot of code to write. I'm quite willing to entertain other solutions, especially if someone's got a nice simple one! -- Clifton -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
