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.

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.

change qa contact to myself,cc esther

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...

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?

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.

I don't know whether they are duplicate.

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?

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).

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.

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.

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

Can someone tell me how I can verify this bug?

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.