1) compose mail 2) attach snap.jpg (from c:\snap.jpg, I'll attach it) 3) send and I hear the disk grind. do we still create a temp file, before sending? If so, we might be reading from c:\snap.jpg and writing to temp.eml in small chunks, and flushing to disk often.

this patch makes it so that external callers of nsIFileStream::Flush() will get the file synced, but internal callers won't. this will return us to the old behaviour, except on the mac, which will sync less (which I believe is desirable)

taking

summarizing a conversation I had with bienvenu over AIM: // To avoid corruption, we flush during a seek. see bug number 18949 - Flush(); + InternalFlush(PR_FALSE); Do we want to do a real flush there? no, I don't think so. The corruption referred to internal buffer corruption. You don't have to do a sync before doing a seek on an actual disk file as long as we call PR_Write of our buffers before PR_Seek we are ok if you look at the normal file io code, you'll never see a sync before a seek

Comment on attachment 106675 [details] [diff] [review] proposed fix sr=sspitzer can you get dougt or sfraser (or someone else who knows nsIFileStream.cpp) to review?

Doug or Simon, can you review this? Thx!

Comment on attachment 106675 [details] [diff] [review] proposed fix r=dougt. I would rather see you move to nsIFile and related IO. if the PR_Write fails, should you delete the file?

I think we rely on the client code to delete the file in case of failure. I too think we should move to nsIFile/nsILocalFile. If we did that, would we just have to rely on the OS/NSPR to do io buffering or is there another file stream buffer class we can use? I believe the original reason for nsIFileStream was that the Mac didn't do file buffering very well. Maybe Simon remembers?

I have no recollection of this, sorry :)

That's fine :-) What's important to know now is if it's OK on the Mac to just use PR_Write and PR_Read w/o application-level buffering? Perhaps this is a moot point if we're really concentrating on just OS/X, and I think the mail code is actually writing larger blocks to the stream anyway, but that's the only issue I can think of w.r.t removing nsIFileStream, besides the work.

fix checked in.

Winxp With 11-18trunk build I took the file, put it in my C:\ directory and then attached it and sent. I heard the grind, but everything went ok, it sent and copied to sent folder. Attachment was OK when recieved. With 11-21trunk build, I ran the same test, I didn't hear the grind and everything went OK for this one too. I expect this is what I was looking for is no grind when attaching the file. Is there anything else I should test. Note: MacOSX didn't have this problem so was this a windows bug only?

yes, Esther, that's it. I'm surprised the mac didn't grind before, but that's fine.

Maybe the mac just has a quieter hard drive.

or a louder fan :-)

What about the smell?

The linux experience was the same as the winxp experience. So It tried Mac OSX again and still no noticible difference between the 11-18 trunk and 11-21 trunk build when attaching and sending this file. Go figure! I guess I have a very quiet & fast (because I didn't see the delay in the Sending like the other systems) Mac. Verified

*** Bug 182080 has been marked as a duplicate of this bug. ***

Moz 1.2, build 20021126, NT4Sp6a [Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2) Gecko/20021126] I can see it on Win NT platform as well, just sending any larger attachement (not just .jpg).

*** Bug 180143 has been marked as a duplicate of this bug. ***

mirek, I took the mozilla build 1.2.1 dated 11-30 and sent a msg with the attached jpg (499kb) and then a larger pdf file (5,245kb) they both sent, but the larger one did the churning thing. It took 2 minutes to assemble, 2 minutes to send and the Sending status box was empty. These 2 files worked fine with the commercial builds dated 11-26 rev 1.3 and the nightly mozilla build rev 1.3. Please take a recent mozilla build and try again. Still verified as fixed.

*** Bug 184515 has been marked as a duplicate of this bug. ***

*** Bug 184620 has been marked as a duplicate of this bug. ***

*** Bug 184817 has been marked as a duplicate of this bug. ***

*** Bug 186988 has been marked as a duplicate of this bug. ***

*** Bug 189701 has been marked as a duplicate of this bug. ***

*** Bug 182373 has been marked as a duplicate of this bug. ***

*** Bug 190696 has been marked as a duplicate of this bug. ***

*** Bug 161829 has been marked as a duplicate of this bug. ***

*** Bug 191631 has been marked as a duplicate of this bug. ***

*** Bug 196804 has been marked as a duplicate of this bug. ***

This bug appears on Win98 also. Win2000 was the listed OS. Has it been fixed in 1.7?

I believe a similar problem was fixed for win98 in 1.6 or 1.7