Closed Bug 49180 Opened 24 years ago Closed 23 years ago

multi-attachment download kill previous downloads

Categories

(MailNews Core :: Networking, defect, P3)

Product:
MailNews Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: mdentrem, Assigned: mscott)

References

(
URL
)

Details

(Keywords: dataloss, Whiteboard: [rtm-] relnote-user) 

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.
QA Contact: lchiang → huang
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
Keywords: relnoteRTM
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
> I saw that Mozilla sometimes download them only halfly

I am seeing the same problem as Ben's mentioned, it seems that we have 
regression on bug 40703 (but bug 40703 is different as this bug) and there was 
existing bug which I logged bug 45720 for 8MB attachments problem before.
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 <mozilla.news@bucksch.org>.
Keywords: mozilla0.8
To Esther ..
QA Contact: fenella → esther
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Mass-change: Do not remove nominations (even if Milestone passed). Readding
mozilla0.8 nomination.
Keywords: mozilla0.8
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
Keywords: nsenterprise
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
Closed: 23 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
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.