At 5:20 PM -0700 9/25/01, Gregory Hicks wrote:
>Good call Randall... Were these in place for popper v3.0.2?
Yes, these have been there as long as I can recall. Years and years.
I'm concerned that you've lost mail, but from looking at the code I
don't see it happening per your theory. There may be something else
going on. I'd strongly suggest upgrading to Qpopper 4.0.3 anyway,
since it has fixed some bugs.
>
>Regards,
>Gregory Hicks
>
>> Date: Tue, 25 Sep 2001 15:32:36 -0700
>> To: "Dan Harkless" <[EMAIL PROTECTED]>, Subscribers of Qpopper
><[EMAIL PROTECTED]>
>> From: Randall Gellens <[EMAIL PROTECTED]>
>> Subject: Re: I lose email when our server crashes due to lack of O_EXCL use
>>
>> At 8:31 PM -0700 9/24/01, Dan Harkless wrote:
>>
>> >It looks to me like what's happening is that my scripts do a POP3 connect
>> >(which I do more often than anyone else, explaining why only _I_ have
>> >noticed mail loss), my spool is emptied out of /var/mail/<user> into
>> >/var/mail/.<user>.pop, the machine crashes, and then after the machine's
>> >back up again, my spool is zero-length and the temp_drop is overwritten by
>> >the first check.
>> >
>> >I didn't pore through the code exhaustively, but I couldn't find any code
>> >that would prevent this. Shouldn't there be code that would check for the
>> >pre-existence of the temp_drop file and merge its messages back into the
>> >spool before doing anything else??
>>
>> There is such code, and has been for as long as I can recall. I've
>> hit it many times in testing.
>>
>> An popper/pop_dropcopy.c:1532, we revert to non-server mode if the
>> temp drop isn't empty:
>>
>> /*
>> * If the temporary popdrop is not empty, revert to regular mode.
>> */
>> if ( mybuf.st_size != 0 )
>> p->server_mode = 0;
>>
>>
>> Then at line 1604 we deal with any left-over mail in the temp drop:
>>
>> if ( mybuf.st_size != 0 ) { /* Mostly this is for regular mode. */
>> DEBUG_LOG2 ( p, "Temp drop %s not empty (%u octets)",
>> p->temp_drop, (unsigned) mybuf.st_size );
>> if ( init_dropinfo ( p, p->temp_drop, p->drop, time(0) ) !=
>POP_SUCCESS ) {
>> /* Occurs on temp_drop corruption */
>> flock ( dfd, LOCK_UN );
>> close ( dfd );
>> return ( POP_FAILURE );
>> }
>>
>> At this point, the file pointer is at the end of the temp drop,
>> following any left-over mail. We then lock the spool, append mail
>> from it to the temp drop (after any left-over mail), zero the spool,
>> and work out of the temp drop.
>>
>>
>> >As I understand things, the only way to prevent any possibility of
>> >overwriting an existing temp_drop file would be to do it atomically, with
>> >O_EXCL specified along with O_CREAT on the open() call.
>>
>> I'm not sure why O_EXCL is needed. Qpopper always locks the temp
>> drop before doing anything, to make sure only one Qpopper process is
>> active for the user. It then checks if the file is non-empty, and
>> processes any left-over mail.
>>
>> --
>
>---------------------------------------------------------------------
>Gregory Hicks | Principal Systems Engineer
>Cadence Design Systems | Direct: 408.576.3609
>555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479
>San Jose, CA 95134 | Internet: [EMAIL PROTECTED]
>
>Tired of BSODs, My Computer, and Code Red?
>http://www.sun.com/solaris/binaries/
--
