378729 - Attachments corrupted on save, if they have content-type: application/applefile

Status: NEW

(Thunderbird :: General, defect)

Description

[Sami Korhonen]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 1.5.0.10 (20070221)

If you send a Photoshop psd-file with Microsoft Entourage (v.11.2.5) , or with Mail.app (v.2.1.1)(and do not check "Send Windows friendly attachment), the content-type is set to application/applefile. When you receive this attachment with Thunderbird, and try to save it and open with Photoshop (v.CS 2), it is corrupted, and Photoshop can't open it.

I'm not sure if this is a VALID content-type, but every other email program can still save the attachment without corrupting it.

If you send same attachment with Thunderbird, Webmail, or Mail.app with "Send Windows friendly attachment" checkboxed, attachments work fine with Thunderbird. 

When sending email, Thunderbird and Webmail set the content-type as 
Content-Type: application/octet-stream;

Mail.app, with "Send Windows friendly attachment" checked, sends Content-Type: image/photoshop;

Reproducible: Always

Steps to Reproduce:
1. Send attachment with Mac Entourage, or Mail.app 
2. Save attachment with Thunderbird
3. Open with Photoshop
Actual Results:  
Photoshop says "Could not complete your request because it is not a valid Photoshop document".

Expected Results:  
Should open up fine.

Comment 1

[Adam Guthrie]

Does this bug still occurs with Thunderbird 2?

Comment 2

[Sami Korhonen]

Yes, Mozilla Thunderbird 2.0.0.0 (20070326) behaves exactly the same.

Comment 3

[Sami Korhonen]

I hope it's the only content type that Thunderbird corrupts, otherwise I would view this bug as quite critical.

Comment 4

[Sami Korhonen]

Attachment: Original test psd-file

This file was created with Photoshop CS2. Create new file, 1x1px 72dpi white background.

Comment 5

[Sami Korhonen]

Attachment: Test psd-file saved with TB20 is corrupted.

Comment 6

[Sami Korhonen]

Attachment: Test psd-file saved with Microsoft Entourage is working.

Comment 7

[Klaus Karcher]

I guess this is a duplicate of Bug 398967 -- from my experience the attachments are corrupted as the resource and data forks are glued together into the data fork. Only Thunerbird on Intel Macs is affected, on PPCs everything works as expected.

Comment 8

[Klaus Karcher]

Attachment: Testcase (saved Email with appledouble Attachment)

Attachment is broken when saved with Thunderbird/2.0 / MacOS X / Intel. This bug is apparently fixed in Shredder/3: Attachment is OK in Shredder/3.0b1pre BuildID 20081115030213, only creation date is wrong (1/1/2000 0:00h). See also (duplicate) Bugs: Bug 394298, Bug 462666 and Bug 398967

Comment 9

[Klaus Karcher]

Attachment <https://bugzilla.mozilla.org/attachment.cgi?id=264737> is obsolete/improper to show the bug as it has no (more) resource fork. Use the saved E-Mail <https://bugzilla.mozilla.org/attachment.cgi?id=348361> as test case instead.

Comment 12

[Mike Smith]

I've seen for some time a problem with Thunderbird/Mac receiving email with attachments from an Entourage client, over several versions of Thunderbird and Entourage.  The attachments are not detached correctly and are partially mangled, which is fatal for image files, etc.  This does not happen with Thunderbird/Windows on the same message, and the message is also correctly readable with Mac Mail client.  The encoded attachment header appears to be slightly different when sent Entourage than from other clients, which must account for the difference, but yet is handled properly by other clients.  I have a couple of examples that I'd make available on request.

Comment 13

[Michael Gabriel]

can confirm. very annoying problem
sent from entourage as appledouble
files are ok with seamonkey 1.1.x on win64

on macosx default viewer doesnt get set correctly and files break on saving.
jpegs work when viewed inline tho.
what i think is happening is that somehow the first contenttype from the resource fork is used and no the second with the actual file.

Content-type: application/applefile; name="Aufbau_Vergleich.png"
Content-transfer-encoding: base64
Content-disposition: attachment;
	filename="Aufbau_Vergleich.png"

Content-type: image/png; name="Aufbau_Vergleich.png";
 x-mac-creator="3842494D";
 x-mac-type="504E4766"
Content-disposition: attachment;
	filename="Aufbau_Vergleich.png"
Content-transfer-encoding: base64

Comment 14

[Maximilian Lucius Fischer]

The described problem is happening here with the most recent thunderbird version (=24.1.0). 

When sent with Windows the content-header looks like that:
--------------020506020303030707040804
Content-Type: application/pdf;
 name="Wall_Detail.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Wall_Detail.pdf"

When sent with OS X (10.9), the content-header looks like that:
--------------010304000708090803060605
Content-Type: application/applefile;
 name="Wall_Detail.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Wall_Detail.pdf"


Is there a workaround available?
Because this bug, as well as other hints, are quite old, it looks to me that everybody else experiencing this found a solution.

Comment 15

[Sami Korhonen]

My solution was to stop using Thunderbird with Mac OS. If you can't trust a mail client to save attachments properly..