User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 When Saving attachments out of the SeaMonkey EmailClient to an USB-stick, the client becomes unresponsive and the process is very slow (6KB/s). This does not happen when storing to the HD. Reproducible: Always Steps to Reproduce: 1. Receive email with attachment of noticeable size (> 1/2 MB) and mount USB-flash-memory-stick 2. Select "Save" from the attachment-context-menu 3. Wait and observe speed much lower than what the Stick is capable of and unresponsiveness of client and download manager. Actual Results: It took 17 minutes to store/export/save an attachment not touching the system it works out fine. High CPU load at times. Expected Results: storing at 8MB/s none

Possible duplicates and similar issues: Bug 587724 - Mozilla becomes unresponsive during USB file transfers Bug 303268 - Very slow "Save As" with "Web Page, Complete" option to USB drive Bug 487375 - Severe performance issues on USB stick while deleting or receiving mail

For some reason I didn't find any good matches prior to entering, but: Bug 303268 and Bug 587724 are similar. The issue seems persistent. My Thumbdrive isn't slow (reads 26MB/s) but it is FAT32 formated

There is another report about saving over network in Firefox that I can't find at the moment. It seems that Gecko stores the files in very small chunks with hurts the performance on the network and might be the reason why some USB Sticks are slow.

According to sid0, it's the chunk size used to stream the file/attachment out to disk/whatever.

That sounds very plausible and should not be that hard to change. In an other related bug-report I read, that it doesn't happen with NTFS formated drives. After some trouble I was able to format the Drive using NTFS with 8KB cluster-size. The problem is gone! One might argue that this is a windows issue, but I doubt MS will do anything about it. Mozilla should make sure data is written asynchronously in chunks >4KB. THIS SEEMS LIMITED TO FAT32 since I was unable to use exFAT under WinXP-Home I can not say anything about it.

moving to core:File handling and confirming

> Mozilla should make sure data is written asynchronously in chunks >4KB. The relevant code in nsExternalHelperAppService.cpp is: 155 // Buffer file writes in 32kb chunks 156 #define BUFFERED_OUTPUT_SIZE (1024 * 32) and that's exactly what we do right now. That's _if_ this is using the exthandler code. If it's not, then what code is it using? Philip?

I've asked someone in #maildev to answer this (I think we have two code paths in MailNews depending on *how* you save attachments - bleah!).

(In reply to Philip Chee from comment #8) > I've asked someone in #maildev to answer this (I think we have two code > paths in MailNews depending on *how* you save attachments - bleah!). Philip, do you call the results of that conversation? http://tinyurl.com/6m6qy6t is a revision of my query from bug 487375 comment 9

Sorry I can't remember if there was any reply to my query.

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #9) > (In reply to Philip Chee from comment #8) > > I've asked someone in #maildev to answer this (I think we have two code > > paths in MailNews depending on *how* you save attachments - bleah!). > > Philip, do you call the results of that conversation? > > http://tinyurl.com/6m6qy6t is a revision of my query from bug 487375 comment > 9 This is an old news. If you click on the attachment icon, it invokes one code path. If you click on "Save" button in the right hand side at the bottom of message window, then it invokes ANOTHER code path. I think the one that is invoked by clicking the icon has a reasonable buffer size now, but I have not checked lately.