From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000813 BuildID: 2000081308 When an email has multiple attachments and in process of downloading an attachment from an IMAP account the downloading a second or more attachment will stop the current download, i.e. only the final downloaded file will not be corrupted, unless you wait until the previous download to finish. Also, probably unrelated; the indicator showing whether the file has been downloaded is not updated Reproducible: Always Steps to Reproduce: 1.from email with multiple attachments start download of an attachment 2 [details] [diff] [review].before completion of the download begin the download of an other attachment. 3.first file should be corrupted Actual Results: Expected Results: A new process for each download that automatically terminates on completion or a new process for download and a separate thread for each download. If the download does not complete reget from where the download left off would be excellent.
Confirming on 20001020 Win95. This is serious! People often delete emails after grabbing the attachments without checking their integrity. This is a dataloss bug. I know it's late, but rtm? Gerv
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss, rtm
Might consider an extremely small and safe patch, otherwise I think this should be minus.
Whiteboard: [rtm need info]
This may be a larger problem then originally thought. When I download a *.tar.gz file the file seems to become corrupted. This seems to happen when downloading though http (I haven't yet tried ftp). To test I down load files with Mozilla and tired to unzip the file. gunzip did not recognize the format. So I ssh-ed to the university and downloaded the file with Netscape 4.61 then ftped that file to my machine where it was recognized by gunzip. This also happens when I download nightly builds from mozilla.org, I must ftp to get a correct file. This in being tested on RedHat Linux 6.1 with build 2000101921. I am using Shaw cable in Victoria, B.C. as my ISP.
OS: Windows 2000 → All
My last comment (i.e. corruption of *.tar.gz files) seems to be only on specific servers. mozilla.org is one of those sites that I have a problem with, but I had no problem when downloading a the Acrobat 4 reader in tar.gz form from adobe.com. Do you think it could be to do with the browser mis-interpreting the gz file as a compressed html file?
Sorry guys, please disregard my last two posts. My brain's been out to lunch. The problem downloading tar.gz file can not be associated with the corruption problem when downloading attachments. It still is a problem though. I will check and make a new report if appropriate.
not an rtm show stopper.
Whiteboard: [rtm need info] → [rtm-]
<fume>. Adding relnote keyword. Gerv
Could this be related to the netlib problem causing data corruption in bug 54081? That bug has a patch, might be worth trying the patch and seeing if it helps here (or if something similar might help). Sounds pretty severe -- users aren't going to trust our mailer if it corrupts their mail upon saving.
What about putting up a busy cursor since the individual downloads appear to be synchronous to the window?
Akkana: I can't try the patch, as I don't build Moz. As soon as that patch gets checked into the branch and trunk, we can try and see. Absolutely. Also, this is more serious than it first appears: any IMAP transaction, whether it be requesting a new message body or another attachment to the same message, will cause downloading to silently cease and the file to truncate. Side note: is the test plan for this area of Mail/News on www.mozilla.org anywhere? Gerv
Gerv: Can you write up the release note item please? I tried, but do not understand the bug well enough to do so.
Ian: The current situation (and I have no idea how this came to be the case, and wasn't noticed for so long) is that _any_ IMAP request triggered using the mail window while attachments are downloading will silently stop the download and truncate the file. The release note would therefore read something like: "If you are downloading a MIME attachment, don't do anything in the mail window until it's finished. You can tell it's finished by the progress bar at the bottom, except when you've done Save All..., whereupon you have to wait for the progress bar to complete the same number of times as there are attachments. Failure to do this could result in silent data loss." I hope that this will not remain the case by RTM :-) I'll write up a relnote as soon as someone decides what we are going to do to mitigate the above nightmare. Selmer's idea is looking more and more promising - I'm just worried people will think Mail has hung... Gerv
By using 10-23-09-MN6 build, I couldn't reproduce this problem. What kind of the attachments and size are you using? Also, my tests didn't cover this area. Peter, do your tests cover this area?
The files I used were mpg, and power point. Reasonably large files. I would expect at least a meg each.
How does this bug relate to inline display, e.g. a mail with 3 attached images? I saw that Mozilla sometimes download them only halfly, some not at all. However, I saw the same in 4.x.
I can reproduce this problem on today commercial win32 2000-102309-mn6 build. Steps to reproduce problem: 0) From Communicator 4.7, send yourself a mail message with three attachment. I had two powerpoint attachment and one zip file. 1) Start Seamonkey 2) Open Mail 3) Select your mail message sent from 4.7 4) Click on attachment button You have three attachments 5) Select the first attachment The save as dialog appears 6) Select the save location to an empty directory (for easy viewing) ** The next few steps should be performed as fast as possible Use large attachment... 7) Save the first attachment The progress bar should indicate the attachment is being saved 8) Select the 2nd attachment and begin the save process before the first attachment is done. 9) Select the 3rd attachment and begin the save process before the 2nd attachment is done. Look at the save attachment and compare the file size to the original attachment. You should see one of the attachment is smaller / corrupted. This scenario is covered under my attachment test spec. It's the last test case which covers corner cases. Normally, you expect end users to use the save all attachment options. http://www.mozilla.org/quality/mailnews/tests/sea-mn-attachment.html
Changing qa assign to myself.
QA Contact: huang → pmock
Whiteboard: [rtm-] → [rtm-] relnote-user
Assign it to myself.
QA Contact: pmock → fenella
This currently isn't planned for mozilla0.8. I've changed the nomination to mozilla0.9 so it gets properly triaged for the next milestone.
Keywords: mozilla0.8 → mozilla0.9
IMO, we should leave those old nominations intact - they show "somebody thought, it should have been fixed long ago". There's no easy way to query for them otherwise. (Can't search for the bug activity history :-( .) If somebody disagrees, please post to .webtools and cc me <email@example.com>.
To Esther ..
QA Contact: fenella → esther
Mass-change: Do not remove nominations (even if Milestone passed). Readding mozilla0.8 nomination.
mscott: ping! :-) I can't believe something this serious is still an issue six months on... Is the current Mail/News work going to fix this? Gerv
Is this still happening?
Tested on W2K with build 2001080103: When I download one attachment of a multiple-attachment mail from an IMAP-server (UW-IMAP), then I cannot download a second attachment of the same message until the first attachment is completely downloaded (shows busy cursor, nothing happens on doubleclick). I can however change to another folder and display messages, and even download the attachment of another message, without breaking the first download. "Save all" sequentially downloads the attachments, no problem there. No dataloss observed, however it would be nice if I could start multiple downloads from one message at the same time and then just have them go on in the background.
This is no longer happening. The attachment download requests appear to be queued, and the attachments are downloaded sequentially. Gerv
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Using windows build 2001-080-28 and save as 5 attachments, from the same message, individually as previous save is going on saves all attachments OK. Verified as worksforme
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.