User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 Iceweasel/20.0 Build ID: 20130402195902 Steps to reproduce: I move message with attachment from an IMPA inbox account to a local storage on a CIFS mounted drive Actual results: It takes ages to complete and sometimes fails by creating ghost message in the destination folder. Doing the same in a windows VM is way faster (same inbox, same version of thunderbird, same mounted share) Expected results: Be faster than on the VM. Its 50x times slower.
could be related to bug 624806. what do you think?
not at work. many informations on newsgroup. relatif to bug on l'on level Linux io. strace shows message is copiedu using 78 char bouffer
I suspect EAGAIN is badly handled
I suspect that 1) EAGAIN is badly handled in some cases, 2) clearly the copy buffer size is crasy, 3) Low level handler of read/write error is quite non robust on Linux, See : news://news.mozilla.org:119/Q6KdnavBq8Cc__DPnZ2dnUVZ_gudnZ2d@mozilla.org there are a lot of infos in his thread.
(In reply to Eric Valette from comment #3) > strace shows message is copiedu using 78 char bouffer dup of bug 769346.
Summary: Moving message from LDAP https inbox to mounted CIFS drive is awfully slow on Linux → Moving message from IMAP https inbox to mounted CIFS drive is awfully slow on Linux
Note that when moving grouped message (e.g a thread) with several attached, not only the copy does not finish even waiting for ages but after, the target directory is unreadable. I have to quit thunderbird, restart, repair the folder and at beast it contains a lot of 0 size messages, at worst some message are missing =W> data lost. The data lost is probably due to bad handling of read/write error code.
I tested 31 beta and the bug is still there. Why the hell is the status unconfirmed when people agree message a re copied using ridiculous small message size. The problme is that due to timeout, when doing big transfers, the target directory on the CIFS share become corrupted and you may lost your copied messages. Minimum is that you have to quit TB, restart it on make restore operation on folder which usually creates a bunch of 0 size messages
Priority: -- → P1
Eric this sounds even more like (at least partly) bug 624806. Does bug 624806 reduce your problem? n.b. priority is a developer field. Please don't touch.
Priority: P1 → --
What in bug 624806?
Copying anything including huge amount of data to the same share in any other apps works like a charm with same setup and the noserverino is set.
yeah, I forgot to finish typing bug 624806 comment 14.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 624806
You need to log in before you can comment on or make changes to this bug.