Subj : Re: Multimail
To   : Matt Munson
From : William McBrine
Date : Thu Mar 08 2001 06:00 pm

-=> Matt Munson wrote: <=-

 MM>> a suggestion for multimail is if the program crashes, the *.rep
 MM>> file shouldnt go down in flames either.

Indeed it shouldn't. But then, MultiMail shouldn't crash, either.

It took me a while to understand how this was actually a suggestion, rather
than a failed attempt at a bug report. Assuming that what you're seeing is 
a deleted .rep ("down in flames" is kinda vague), there are only two places 
where MultiMail deliberately removes it: when you say 'N' on entering a 
packet, and just before a new packet is created.

I took a look at the code for the latter, and I made a change. It was doing
this:

 delete old .rep
 write out replies
 zip up new .rep

For the next release, I've changed that to:

 write out replies
 delete old .rep
 zip up new .rep

So, if it crashes during the "write out replies" phase, the old .rep packet
will still be there. I don't know whether or not this will actually help
you, because you don't give enough information for me to tell what's
happenning. But it turned out to be a good suggestion anyway. :-)

What I'd really like to do, though, is fix the crash. It shouldn't be
crashing, period. To fix that, I need a LOT more information -- preferably,
a reproducible sequence that leads to a crash with a given set of data,
along with a copy of that data. Believe it or not, this:

 MM> Win32 version, the program crashes after building reply packet.

isn't enough to go on.

BTW, my current recommendation is that the Win32 version be used only under
NT, and that the "DOS" (DPMI) version be used under Win 9x. (2000 should be
the same as NT, and ME the same as 9x, but I haven't tested those.)

.... The number you have dailed...Nine-one-one...has been changed.
--- MultiMail/Linux v0.39
 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

.