71025 - Mail message lost in crash while downloading mail

Status: VERIFIED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[Don]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; 0.8) Gecko/20010215
BuildID:    20001021503

Mozilla seems to download the mail and delete from the server it BEFORE saving
it to disk... So when Mozilla crashes in that period of time in between the
e-mail message will be lost...

Reproducible: Didn't try
Steps to Reproduce:
This just happeneds coincidental.

Actual Results:  The last e-mail got lost.

Expected Results:  Save the e-mail or not delete it from the mail server yet.

Comment 1

[James Paige]

I am unable to reproduce this on Windows 95 (build 2001030505)

I sent myself a mail with a really big attachment (to ensure a nice long
download time) and then checked my mail, and hard-killed my computer with a
double-CTRL+ALT+DELETE (ah! the things I do for Mozilla!)

After booting up again (and scandisking, and reparining the file corruption in
my mail folder) I reopened Mozilla, and found the corrupt mail in my mailbox. It
crashed mozilla when trying to view it, but by hiding the message pane I was
able to select it to delete it. I then checked my mail again, and the mail was
still there on the server. It came through fine.

Comment 2

[Sheela Ravindran]

change qa contact to myself,cc esther

Comment 3

[Don]

The problem seems to be in the order Mozilla handles new e-mail. I think it just
crashed here in a REALLY unlucky moment... Because it hang exactly when the
download was completed but the message didn't show up yet...
I think that rather then trying to recreate the problem the order deleting and
saving e-mail should be checked and changed...

Comment 4

[Sheela Ravindran]

This is sounds like a duplicate of bug 70460.  The only difference is that one
bug has reported that mail is lost and the other bug reports that mail was still
on the server.  Navin any comments?

Comment 5

[Navin Gupta]

reporter, you can check off "Leave Messages on the server" before you
begin downloading messages. This pref is in Edit MailNews account settings
under Server settings.

Comment 6

[Navin Gupta]

I don't know whether they are duplicate.

Comment 7

[Don]

I'll try to make it more clear, the crash was pure coincidental...
I think that the normal procedure is like this:
Check mail->download mail->delete mail->save mail to disk->close connection
Now, the following happened:
Check mail->download mail->delete mail*CRASH*
So the mail actually hasn't been saved to disk... it was only a small e-mail so
I guess it was still compeletely buffered.
The simmulationCheck that was attempted to be done went like this:
check mail->download mail*RESET/CRASH*
So the mail didn't get deleted yet and because of the big attachment I guess it
saves the message more frequently.

The normal procedure works fine normally, unless in the rare event a crash
occures exactly between deleting and saving the e-mail... But ofcause it's not
as fool proof as it should be.
A better procedure would be like this:
Check mail->download mail->save mail to disk->delete mail from
server->disconnect connection to server
With mail I mean an individual e-mail message in this case, in my case it was
actually the last message, the previous one was indeed saved...

Could someone check my theory with the source code?

Comment 8

[J Luh]

I asked the same question in bug 55814, and someone else answered that Mozilla
does not confirm that the message has been written to disk before it deletes the
message from the POP server. That bug dealt with the specific case of the disk
being full, but I think this problem should be fixed for the general case (i.e.
Mozilla should delete a message from the server only if it can confirm the write
succeeded).

Comment 9

[Sheela Ravindran]

Navin,
Can you please add your comments to the reporter's questions on  2001-03-06 
13:28.  Depending on what the answer is, please confirm this bug. I cannot 
reproduce this problem at this point. 

Comment 10

[Navin Gupta]

Bug #71666 deals with hitting "Stop" which results in messages getting lost. But
I have a fix for #71666 that I will land soon. #71666 should fix this bug also.

Comment 11

[Navin Gupta]

I have fixed a lot of related bugs lately, #55814, #67799, #71666. I think this 
should be fixed. Marking fixed

Comment 12

[Sheela Ravindran]

Can someone tell me how I can verify this bug?

Comment 13

[Sheela Ravindran]

okay,
I have waited too long...I am marking this bug as verified since recreating this 
scenario is very hard.  If anybody finally thinks of one reopen and I will 
verify it again with a given test case. For now marking this verified.