231508 - Aborting and restarting slow IMAP attachment download results in corrupt message

Status: RESOLVED EXPIRED

(MailNews Core :: Networking: IMAP, defect)

Description

[Gerrit Hannaert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040114
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040114

When downloading a fairly large attachment from an IMAP server by clicking on
another message *while the download has started* the download will properly
abort but it is impossible to retrieve the attachment ever again - it always
seems corrupt (partially downloaded). Perhaps some bad IMAP caching?
With fairly large I mean I've tested sizes as low as 250kB and up to several MB. 

Oddly, copying the message to another IMAP server (over SSL, on another site)
and downloading the attachment there results in 0 byte file. Probably totally a
coincidence, but it bit me twice.

Possibly related to Bug 137338?

Reproducible: Always

Steps to Reproduce:
1. Click on message with attachment(s), the larger the easier it is to abort it ;-)
2. Click on another message, the download aborts (or appears to, perhaps it
shouldn't)
3. Click on the original message and try to get the attachment intact!
Impossible! (as far as I've tried)



Expected Results:  
Attachment download should have either continued where it left off or restarted.

IMAP server: MDaemon 6.8.5 / Windows 2000 Server

Comment 1

[Dennis]

The same happens to here. Same environment, except that the mail server is UW IMAP.

I'm not using the download manager, for downloads. Instead I use the standard
progress dialog

Eventually using the download manager could be a work around for this. I did not
test yet.

Comment 2

[Simon Gibbs]

Also spotted in user agent "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20040910".

I have configured the most troublesome folders for offline access, turned that
off, back on again and hit the Download Now button several times over. Whatever
I do I get the impression that Mozilla regards the message as properly downloaded.

It would be nice to have some way to tell it to start afresh. Hitting
View->Reload does nothing (is this pointed towards HTML handling?).

SJG

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 5

[Gerrit Hannaert]

I recently tried and was unable to reproduce on a recent Thunderbird, although I
haven't tried with Mozilla suite.