Closed Bug 330829 Opened 18 years ago Closed 14 years ago

IMAP. TB not always downloads attachments

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 390795

People

(Reporter: ezh, Unassigned)

Details

Attachments

(2 files)

Using IMAP sometimes TB does shows the presents of an attachment, but fails to download it, or load's only part of it.

There is no other way to reload the attached files, than going to web interface.

TB 20060311 Trunk (and previous releases)
BTW. The larges the attachmet is, then the chance of such result is bigger.
is this reproducible? is this always .png attachments that don't display? If you copy the imap message to a local folder, do the png attachments display correctly?
I have restarted the computer, copied the messages to Local Inbox folder. It just copies the same content without to redownload it. Does not redownloads it.

It is very good to have a cached message on computer, but I would have a option to "Reload message from server".

I have the "Select this folder for offline use" off.

I cannot tell is this only png issue or not. 


PS Now I have found cached .gif and .zip. And that folder is set for offline usage.

Can I turn on some logs for you?
And this happends not always, just sometimes. 
Do you have the folder configured for offline use? To me, this sounds like a problem with the message itself, not IMAP... Can you forward (as attachment) to me one of the messages that's not displaying correctly?
Attachment #215412 - Attachment is patch: false
Attachment #215412 - Attachment mime type: text/plain → image/png
Sent you 2 mails. The second message (with CD) is gone somewhere... :-/

But I have the image saved from the web and forwarded. In sent in is shown in fullsize...

The CD was in folder for offline usage. The message woth 2 pictures that does not shown are configured to _NOT_ using offline usage.
Component: General → Mail Window Front End
QA Contact: general → front-end
(In reply to comment #4)
> is this reproducible? is this always .png attachments that don't display? If
> you copy the imap message to a local folder, do the png attachments display
> correctly?
> 


Since I've updated to SeaMonkey 1.1.2 (rv:1.8.1.4, Gecko/20070509, Win2K), I'm experiencing this problem with different kinds of attachments (.ppt ~0.5 MBytes, .wmv ~1 MByte and .xls ~40 KBytes that I remember right now). When I was using Mozilla Suite 1.7.12 (also on Win2K), I didn't have this problem.

The IMAP server is MS Exchange (I don't really know version and patch level, since I'm not administering), but I'm pretty sure the problem doesn't lie in the message itself because I can access to it through MS Outlook 2000 and save the attachment without any problem.

I think this bug is related to (or duped with) all these others: bug 220281, bug 262716 and 301541.
Yesterday experienced the same problev using Gmail IMAP.

TB 2007102503
To Eugene Savitsky(bug opener):   

Same problem as Bug 386514 or Bug 384819 or Bug 405440 ?
(In reply to comment #10)
> Yesterday experienced the same problem using Gmail IMAP.
Possibly same problem as Bug 403032 & Bug 403039 (i.e. DUP of Bug 390795 which is non-MS-Exchange version of Bug 92111) when Gmail IMAP.

To Ricardo Palomares:   

(In reply to comment #9)
> The IMAP server is MS Exchange
Possibly same problem as Bug 92111.

To Eugene Savitsky(bug opener) and Ricardo Palomares:

Anyway, get IMAP protocol log and check real protocol level flow.
See Bug 402793 Comment #1 for getting IMAP protocol log.

(In reply to comment #11)
> To Ricardo Palomares:   
> 
> (In reply to comment #9)
> > The IMAP server is MS Exchange
> Possibly same problem as Bug 92111.


In the end, I applied the workaround commented in:

https://bugzilla.mozilla.org/show_bug.cgi?id=92111#c45

and it has solved the problem for the last ten days or so, so I think the non-standards ball is indeed in the MS side (heck, what a surprise!) }:->>

I've noticed that inline attachments such as screenshots disappear from mail that I've sent, leaving only an icon placeholder when I either resend them (Edit As New) or try to forward. I can still see them in the original. Size is not an issue. What I have noticed though is that TB may be using a protocol ID of

map://

vs  what I THINK it's supposed to use, which is

imap://

to find the attachments now stored on the server.  Example:

map://philwells%40philwells%2Enet@zcs.spamcurb.com:993/fetch%3EUID%3E/Sent%3E27552?part=1.2&filename=moz-screenshot-2.jpg"

The emails were either created in the latest build of TB 3a1 or in another app like Apple Mail because version 2.0.0.9 (20071031) doesn't allow pasting screenshots.

The ORIGINAL email shows up at the recipient OK w/ the screenshot intact.
Assignee: mscott → nobody
In version 2.0.0.21, if the email is viewed before it's finished downloading from IMAP and stored to an offline folder, the attachment is broken and will NOT re-download.  It may be localized to Windows only as I can't re-produce this on Mac release.
Flags: blocking-thunderbird3?
Not marking as blocking until we have a better understanding of the frequency of occurrence, esp. with standards-following servers.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
I have experienced partial attachment download many times with IMAP (no, not only on Gmail). The attachment becomes corrupted. It is quite annoying because there is no way to re-download the message. Don't know if this has anything to do with fact I have set the folder for offline use.

A simple "Reload" function like the one available on web browsers is really needed. If an attachment download is not completed due to a network failure, Thunderbird does not re-fetch it again.
To bug opener & all problem repoters:

Get IMAP log when your problem occurs first, and check IMAP level flow by yourself.
> Getting NSPR log                     : See Bug 402793 Comment #1
> IMAP command/response                : http://tools.ietf.org/html/rfc3501
If you are MS Win user, timestamp can be added to log.  
> Adding timestmap to log by DebugView : See Bug 402793 Comment #6

If(and only if) Tb's flaw is found in IMAP log, and if log analysis by developers is required, attach log file to this bug(text/plain if file size is accepted by buzilla.mozilla.org. Never paste, please).
No response for more than one year...
Closing as Dup of 390795 per next comments.

> (comment #10 by Eugene Savitsky, bug opener. See bug 403032 and bug 403039)
> Yesterday experienced the same problev using Gmail IMAP.
> (comment #12)
> In the end, I applied the workaround commented in:
> https://bugzilla.mozilla.org/show_bug.cgi?id=92111#c45
> and it has solved the problem for the last ten days or so, so I think the
> non-standards ball is indeed in the MS side (heck, what a surprise!) }:->>
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: