multi-attachment download kill previous downloads

VERIFIED WORKSFORME

Status

P3
critical
VERIFIED WORKSFORME
19 years ago
11 years ago

People

(Reporter: mdentrem, Assigned: mscott)

Tracking

({dataloss})

Trunk
x86
All
dataloss

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-] relnote-user, URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
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

Comment 2

19 years ago
Might consider an extremely small and safe patch, otherwise I think this should
be minus.
Whiteboard: [rtm need info]
(Reporter)

Comment 3

19 years ago
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
(Reporter)

Comment 4

19 years ago
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?
(Reporter)

Comment 5

19 years ago
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.
(Assignee)

Comment 6

19 years ago
not an rtm show stopper. 
Whiteboard: [rtm need info] → [rtm-]
<fume>.

Adding relnote keyword.

Gerv
Keywords: relnoteRTM

Comment 8

19 years ago
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.

Comment 9

19 years ago
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

Comment 13

19 years ago
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?
(Reporter)

Comment 14

19 years ago
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.

Comment 16

19 years ago
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

Comment 17

19 years ago
Changing qa assign to myself.
QA Contact: huang → pmock

Comment 18

19 years ago
> 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
Keywords: mozilla0.8

Comment 19

18 years ago
Assign it to myself.
QA Contact: pmock → fenella

Comment 20

18 years ago
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

Comment 22

18 years ago
To Esther ..
QA Contact: fenella → esther

Updated

18 years ago
Keywords: mozilla0.8.1

Updated

18 years ago
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

Updated

18 years ago
Keywords: nsenterprise

Comment 25

18 years ago
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

Comment 28

18 years ago
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.