Closed
Bug 680004
Opened 13 years ago
Closed 6 years ago
IMAP: TB claims error "This attachment appears to be empty" after message was moved into another folder (but attachments are present in source)
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1430480
People
(Reporter: madhu, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: testcase-wanted)
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1
Steps to reproduce:
I'm using Thunderbird 6 and my email is with gmail. I configured it using imap.
I moved a mail from inbox which has attachments to a folder / sub folder. Before moving, I'm able to download attachments.
Actual results:
The mail moved to folder / sub folder successfully. But when I try to download the attachments from the mail from the folder / sub folder, it is saying that the attachment appears to be empty. But when I open my mail in web, that attachment exists and it is allowing me to download the attachment.
Expected results:
Even though I move mails from inbox to any folder / sub folder, it should allow me to download / open the attachments.
Comment 1•13 years ago
|
||
Madhu, we need testcase.eml which works in webmail but breaks in TB (remove private data as required).
Keywords: testcase-wanted
Updated•13 years ago
|
Summary: Problem with Attachments download from mails in folders / sub folders → IMAP: TB claims error "This attachment appears to be empty" after message was moved into another folder (but attachments are present in source)
Updated•13 years ago
|
Priority: P3 → --
Updated•13 years ago
|
Attachment #554007 -
Attachment description: No attachments.png → Screenshot: Error message "This attachment appears to be empty"
Comment 2•12 years ago
|
||
Similar issue for me. Reported here:
https://bugzilla.mozilla.org/show_bug.cgi?id=770888
Comment 3•12 years ago
|
||
Updated•12 years ago
|
Attachment #652515 -
Attachment mime type: application/octet-stream → text/plain
Comment 4•12 years ago
|
||
I took the email from https://bugzilla.mozilla.org/attachment.cgi?id=652515 and put it in a local folder, then copied that email to a local folder. I had no issues with the attachments in the local folder.
This must be IMAP or GMail related and not MIME related.
Comment 5•12 years ago
|
||
I am experiencing this as well, thunderbird 15.0, running on windows 7.
Attachments can be read and moved from one IMAP account to another. If, however, I move an attachment from a dovecot (or other) IMAP server to a gmail IMAP account -- into a subfolder -- the attachments are no longer viewable through Thunderbird. I can still get to those emails via the gmail web interface.
Comment 6•12 years ago
|
||
(In reply to Kent James (:rkent) from comment #4)
> I took the email from https://bugzilla.mozilla.org/attachment.cgi?id=652515
> and put it in a local folder, then copied that email to a local folder. I
> had no issues with the attachments in the local folder.
>
> This must be IMAP or GMail related and not MIME related.
Kent, I don't think the issue happens when coping to another local folder, it needs to be a sub-folder of another account, just like Jeremy reported. Also, it doesn't happen immediately. Some times it's a few days later...
Would the .msf file from one of these folders where the attachments can't be viewed, be of any help?
Comment 7•12 years ago
|
||
(In reply to Barry Ralphs from comment #6)
>
> Kent, I don't think the issue happens when coping to another local folder,
> it needs to be a sub-folder of another account, just like Jeremy reported.
> Also, it doesn't happen immediately. Some times it's a few days later...
> Would the .msf file from one of these folders where the attachments can't be
> viewed, be of any help?
Probably not at the moment.
What the bug needs are steps to reproduce that a developer could go use to actually see the issue. Without that, it needs to be clearly affecting a lot of people to get much attention.
Comment 8•12 years ago
|
||
I to wish I could reproduce it consistently, but it's been very random, where & when it happens...
Comment 9•12 years ago
|
||
These are my steps to reproduce it EVERY TIME:
1) connect to your gmail account via IMAP in thunderbird.
2) send an email with an attachment to your non-gmail account, also configured in thunderbird
3) move the email with the attachment from your imap account to a subfolder of your gmail account (e.g. a label you have created at some point in gmail)
4) go to www.gmail.com and verify that the attachment moved properly.
5) try to open the attachment via thunderbird -- you will get the 'attachment is empty' message.
I have verified that the attachments have moved properly for dozens of emails -- but none of them will open properly.
Does this set of instructions help?
Comment 10•12 years ago
|
||
(In reply to Jeremy Anderson from comment #9)
> These are my steps to reproduce it EVERY TIME:
> ...
> 3) move the email with the attachment from your imap account to a subfolder
> of your gmail account (e.g. a label you have created at some point in gmail)
Does that mean I should move the msg from imap-gmail's Sent folder in TB to imap-gmail's Important folder? Did that.
> I have verified that the attachments have moved properly for dozens of
> emails -- but none of them will open properly.
> Does this set of instructions help?
No, I tried to follow instructions religiously and everything worksforme as expected, can open attachment from msg moved within TB's imap-gmail account, and now in TB's imap-gmail "Important" folder.
(In reply to Barry Ralphs from comment #6)
> (In reply to Kent James (:rkent) from comment #4)
> > I took the email from https://bugzilla.mozilla.org/attachment.cgi?id=652515
> > and put it in a local folder, then copied that email to a local folder. I
> > had no issues with the attachments in the local folder.
> >
> > This must be IMAP or GMail related and not MIME related.
>
> Kent, I don't think the issue happens when coping to another local folder,
> it needs to be a sub-folder of another account, just like Jeremy reported.
From which type of account/folder to exactly which type of account/folder should we move (or copy?) the message?
> Also, it doesn't happen immediately. Some times it's a few days later...
> Would the .msf file from one of these folders where the attachments can't be
> viewed, be of any help?
Somehow this "a few days later" reminds me of Bug 532395 or some other compaction-related bugs.
Comment 11•12 years ago
|
||
Madhu.T., reporter, on the affected IMAP account in TB, what's your setting for
Tools > Account Settings > Affected IMAP account > Synchronisation & storage > [ ] Keep messages for this account on this computer ?
Comment 12•12 years ago
|
||
- I have the same problem. I am using the latest TB ESR 17.0.3
- I did not have this problem with TB ESR 10.x.
- I have also noticed that this issue was present on TB 16, and maybe even earlier. This issue was one of the reasons why I stayed on ESR version 10
Description:
- I have one IMAP account connected to "CommuniGate Pro"
- I have second IMAP account connected to Zimbra.
- When I move message from CommuniGate Pro Inbox to Zimbra Inbox (i.e. folders between accounts), I am not able to open attachment anymore at the destination folder.
- I am NOT keeping messages locally (for both accounts) i.e. Synchronization & storage > Keep messages for this account on this computer
Regards,
Igor
Comment 13•12 years ago
|
||
Just to add the following:
- if I do Properties and Repair folder on the destination account i.e. Inbox, attachment is again available.
Seems that folder index ( .msf or whatever) is not immediately updated when the message is moved to that folder.
- restarting TB without Repairing the folder does not help.
Comment 14•10 years ago
|
||
I have this problem when using filter rules manually.
Steps to reproduce:
Send an email containing an attachment to a gmail-address
Receive the email
Create a subfolder
Create a filter rule that moves the sent mail to the subfolder
Run the filter rule manually
Try open the attachment
Updated•10 years ago
|
Component: Folder and Message Lists → Backend
Product: Thunderbird → MailNews Core
Comment 15•10 years ago
|
||
To add another simpler axample, my email was changed recently to Office365 using IMAP Mail Server (from a POP Mail server).
I use Message Filters heavily to sort incoming mail.
Mail attachments that I am positive that I have opened previously (received via Office365) now fail to open with the "empty" message (I only tried with PDF's).
Running a Properties/Repair Folder on the folder containing the message with the apparent "empty" attachment makes the attachment(s) visible (tried on PDF's that previously failed as well as docx's).
Comment 16•10 years ago
|
||
Thanks Igor Vitorac this sorted it for me. I only use gmail imap accounts, not Local or other service providers email.
Comment 17•9 years ago
|
||
I have this issue too with two different IMAP accounts, with an ever reproducible behavior :
1) Receive mail with attachment in Account 1/INBOX.
2) Move it to Account 2/INBOX.
3) Try to open attachment, it fails.
4) Go to webmail of Account 2, open the mail and its attachment → it works.
Note that Account 1 is actually mbox while Account 2 is maildir, but not sure whether this is relevant.
Repairing using the button .msf doesn’t work. Deleting it and restarting TB does.
Comment 18•9 years ago
|
||
b.pagani: If you are having issues using maildir, or maildir mixed with mbox, please open that as a separate bug. The issues of maildir are still being resolved, and are likely different from whatever is the root issue of this bug.
Comment 19•9 years ago
|
||
Well, I’m not sure whether this is related to mbox/maildir, I was just mentioning it in case it could matters.
Comment 20•9 years ago
|
||
I'm putting here the same comments as I did for 917390 as I'm not sure where it should land:
The same issue with TB on Mac 10.11.4 and all previous.
Both current version - 38.7.1 - and all previous ones.
The issue is: sometimes attachments cannot be opened by TB.
There are 2 workarounds:
1- use another client on the same IMAP. This however makes TB useless
2- right click on folder -> Properties -> Repair folder. This however kills all settings for the folder: custom columns, sorting etc
While looking at the source of message (Cmd+U) the header of attachment is (however not pdf only has this issue - any attachment and not always):
--------------080506060605000005010706
Content-Type: application/pdf;
name="CCF20160401_00001.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="CCF20160401_00001.pdf"
When I saved source of message before "Repairing folder" and after it and used diff to compare them, there is COMPLETELY NO DIFFERENCE. It tells me it is NOT message issue.
Mail server: local "Mac Server" with IMAP.
Let me know if you need more info - it is not convenient to keep 2 email clients on my Mac.
Comment 21•8 years ago
|
||
I have a very similar problem since a few days.
- Using 2 PC's with Win7 64 bit and 1 PC using WIN7 32 bit, with all available updates
- All have latest Thunderbird 45.2.0
- All have the same folder structure, showing 5 mail accounts simultaneously
- 4 mail accounts have no problems
- the aol account on the Dell 760/Win7 64bit is the only one which has a problem with jpeg attachments, as follows:
- mails with the .jpg atachment in the inbox folder display correctly
- however when I move the mail to a subfolder the jpeg does not show, I get the message "this attachment appears to be empty". I iws not empty, it shows the correct size of about 350kB. When I move it to the trash folder (or to any other folder) the pictures appears! When I try to download it it doesn't download and I get no error messages.
Comment 22•8 years ago
|
||
Forgotten in my previous comment: "repair" of the problem folder causes the jpeg to show up correctly, but doesn't cure the problem for subsequent mails
Comment 23•8 years ago
|
||
Last update as of Tuesday July 5 17:00
This is kind of embarrasing, but as of this morning around 8:00 the problem has disappeared.
I can only say it definitely was a real problem I checked at least 20 times over the previous 48 hours and it was each time 100% reproducible.
Comment 24•8 years ago
|
||
I’m keeping having this issue with maildir vs mbox account.
Comment 25•8 years ago
|
||
I confirm this bug, I'm using TB 45.4.0 on GNU/Linux, my email accounts are imap ONLY, i.e., I work with dovecot running on localhost
Comment 26•8 years ago
|
||
Same issue here with Thunderbird 52.1.1 64-bit on Linux Mint 18.1 accessing my corporate MS exchange account via IMAP.
Comment 27•7 years ago
|
||
I confirm this bug on Thunderbird 54.0 on Linux and also on earlier versions on Windows (using IMAP), and "repair folder" doesn't fix it. (See also 647562 and 770888.) I've seen this problem only with messages originating from Apple mail. Perhaps it's related to the formatting of the message: looking at the source shows that there is no empty line between the first uuencoded attachment and the second. They follow like this:
[everything including the beginning of the first attachment]
...
Lfx+rgaQJsC4E2BcAcRQpCoAmbAvrAFY1AmwMzSAQBSXFCqKmYTjjiBNgXArQMwJomKqxFCqKgBg
/wD4uv/Z
--Apple-Mail=_2684EB11-E4BB-446B-A452-DE2F459E724F
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename=Second-attachment.jpeg
Content-Type: image/jpeg;
x-unix-mode=0666;
name="Second-attachment.jpeg"
Content-Id: <6D430DA6-6A30-43C6-BC24-6242A5AB9207@arnhem.chello.nl>
/9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QN9aHR0cDov
...
I can easily decode the base64-encoded parts when I save the raw message. FastMail's web interface has no problem with them, and can properly display and download them. So my guess is that Thunderbird is being too careful with messages that don't quite meet the standard for delineating attachments.
Comment 28•7 years ago
|
||
Sound like the same problem as bug 1430480 that I am working on a fix for.
Comment 29•7 years ago
|
||
Perhaps, but the problem also happens with other binary attachments. On my systems I first noticed it with both JPEG and ODT (LibreOffice document -- zip file format) attachments.
I use Thunderbird in text-only mode with the "Allow HTML Temp" extension. When a message arrives that uses HTML, whose attachments aren't indicated, clicking to show the message in HTML causes Thunderbird also to display the attachments.
Comment 30•6 years ago
|
||
I see this, too, on Windows (TB 52.9.1) when I move mails from IMAP account A to IMAP account b hosted on the same server. When I move the message back to the original folder, I can again access the attachment.
Comment 31•6 years ago
|
||
(In reply to Daniel Kabs, reporting bugs since 2002 from comment #30)
You might try the beta and see if the changes applied in bug 1430480 fix it. I had to make some compromises to my original fix proposal to pass unit test, but hopefully what you see will be fixed in the beta and next esr release.
Comment 32•6 years ago
|
||
I am running Thunderbird 52.9.1 on Mac OSX 10.13.6.
I can confirm this bug, too.
I receive an email from a client with an attachment. The filters run automatically and move the email to a folder which is three levels deep (i.e. account>Spencer'sFolders>-Clients>client). Reading the email, and attempting to open the attachment results in an error message, "Attachment appears to be empty". I move the email to the Inbox. Attachment opens just fine. I move the email back to the folder, three levels deep. Now, the attachement behaves normally.
Comment 33•6 years ago
|
||
(In reply to Spencer Webb from comment #32)
> I am running Thunderbird 52.9.1 on Mac OSX 10.13.6.
>
> I can confirm this bug, too.
See comment 31 above. If you could test this with the beta it would be appreciated!
Comment 34•6 years ago
|
||
Well, no feedback from anyone, so I've decided it's fixed by bug 1430480 ;-)
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Comment 35•6 years ago
|
||
(In reply to Jorg K (GMT+1) from comment #34)
> Well, no feedback from anyone, so I've decided it's fixed by bug 1430480 ;-)
Thanks. I missed this somehow.
Just tried with TB60.4 which should include the fix and I could not reproduce the issue any more. Great!
You need to log in
before you can comment on or make changes to this bug.
Description
•