I sent a 2.5 meg file (a powerpoint presentation) and two strange things happened: a) The file was corrupted. roughly 4 bytes (yes four itty bitty bytes) were were missing (i.e., the size was wrong, though I don't know if the bytes that arrived were correct). b) The sent email was *not* posted to my IMAP sent folder (unlike all the other email I sent before and after this message). I'd call this data-loss, and data corruptions. Nominating for dogfood and beta1.

rhp is out today. Jeff, can you look into this?

sure.

jar, is it possible for you to attach the 2.5 meg file to the bug?

I sent two copies of the big attachment, one via 4.x, and via seamonkey, to jefft. I don't want to clog up the bug database with multi-meg files, and get the wratth of mozilla upon me. If the files I sent come across the "same size," then I'll try demoing this another way (there is a chance that a file-shortcut was used when I sent the file the other day :-/ ).

5.5 meg zip file with local Sent folder sent fine for me when using imap account on a 2x56k ISDN line. Will do more investigation.

Copy made to the local Sent folder was corrupted though.

PDT+

Okay, I have a safe fix in hand. A simple file stream flush will do the work.

Never mind. Proposed fix seems not the right fix. Since, m_fileStream->close() supposely should call the flush(). Unless the m_fileStream->close() never gets called.

jeff / jar - pls send me the file so that the bug can be verified once fixed.

I can see a new patch listed above. Is it checked in? Does it solve the problem? Lisa is asking for a test file... but it is not clear that this has landed anywhere :-/. Please update the status whiteboard, including timeline for landing. Thanks, Jim

Not quite fix yet. ETA 3/17. Lisa, I will send you the file.

Closing down compose window never returns which cause copy state never gets cleared. Hence the file stream never gets appropriately closed. This seems the root of the problem.

What do you means exactly when you say "Closing down compose window never returns"? Also, could you apply the fix I have for bug 31568 which affect the way we manage failure when processing attachment during a send process. That might be part of your problem too!

mComposeObj->CloseWindow() never returns. We hang after that as of my debug build.

Bug 31568 has nothing to do with this. It handles the error returns.

Funny, the window closing problem happens on my home compaq 6200 machine but not on hp kayak machine. Hmm....

Private release build with the second patch tested on slow machine works fine. Need to test on a slow link too.

All of a sudden I couldn't create the problem on suresh's 133 mHz machine with today's build. I was able to recreate the problem on my home machine yesterday. I don't know what to do now.

Fix check in. Note to QA, you may or may not be able to reproduce the problem using the previous build. It all depends on whether you can hit the buffer bundary or not. Different platforms or recipients and content of body message can create different results.

Peter, please verify by just sending large attachments to make sure that no corruption occurs. Perhaps over a modem line if you get a chance.

Hi Lisa, I will work on verifying this bug tomorrow in our lab. I need to bring in my secure id card in order to test via modem. /Peter

Verified as fixed using on Win32 and linux using the following builds: -win32 commercial seamonkey build 00042109-m16 -linux commercial seamonkey build 00042416-m16 File comparsion between original test file and 5.0 sent test file were the same. Verified as fixed

fyi, I tested over the lan and via slow 28800 modem connection.