Closed Bug 361401 Opened 13 years ago Closed 12 years ago

nsAppleFileDecoder assumes big-endian platform, effectively corrupts AppleDouble thunderbird mail attachments

Categories

(Core :: Networking, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.1b1

People

(Reporter: moco, Assigned: asuth)

References

()

Details

Attachments

(2 files, 1 obsolete file)

images I save from a certain message are corrupt, problems with AppleDouble encoded Macintosh files?

I'm using version 2 beta 1 (20061118)

I have a message that someone sent me from a mac, and I can see the images in the message, but when I try to save them, and then open them, they are corrupt.  (see screen shot)

when I do "file" on the saved image, I get "AppleDouble encoded Macintosh file" instead of "JPEG image data, EXIF standard 2.2", which I get when I save the message from Mail.app

I'll attach some screen shots and the test message
Attachment #246167 - Attachment is patch: false
Attachment #246167 - Attachment mime type: text/plain → image/jpeg
I am having a similar problem. On Mac OSX thunderbird version 1.5.0.0, an email with four attachments (two files, two "application/applefile") only two attachments show up and when saved they are corrupt. I can forward this email on request, but can't make it public because of copyright issues.

The original email checked through another IMAP client (squirrelmail) shows four attachments, and can download the files correctly.

When forwarding this email to examine on another PC, the files seem to have been changed to a different mime type. When forwarded as inline, there are magically four attachments rather than the two seen in the reader window.

My guess is that this is overly complicated attachment handling. The original sender was AppleMail, which has given us grief for years. Please save me from having to install two email clients (Thunderbird and AppleMail) on all of our Macs.  O_o
sorry, previous message should have read version "1.5.0.9" rather than "1.5.0.0".
This is a dupe of bug 353529.  I think bug 367739 is the same problem.
Flags: blocking-thunderbird2?
Moving off bugs that didn't make the deadline for Thunderbird 2. 
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Target Milestone: --- → Thunderbird 3
Duplicate of this bug: 367739
See my comment on Bug 353529  (I should have put that comment here, but I suspect the cause is the same as on Seamonkey.)

In my case, the corruption happens for Thunderbird 2.0.0.12 on an Intel Mac but does not happen for Thunderbird 2.0.0.9 on a PPC Mac, nor for Mac Mail or Entourage on the Intel Mac.

The corruption appears to be that the file has extra data caused by prepending the other segment of the AppleDouble file.  The problem for me occurred on the 3 file types I tested (.doc, .ppt, .xls) so I suspect it is generic across all file types.


Can you reproduce with Thunderbird v3.0a2pre too ?
Flags: wanted-thunderbird3.0a2?
Flags: blocking-thunderbird3?
Version: unspecified → 2.0
The problem still remains with Thunderbird v3.0a2pre of 5/18/08 10:52:00 AM for the Mac.

I shut down TBird 2 and downloaded the version from 
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
and ran it (version 3.0a2pre (2008051803)).  I then found email I had received a few months back with the problematic AppleDouble attachments.  I tested the PPT, DOC, and XLS files.  I downloaded those attachments and tried to open each.  Each application complained about the format of the file.

These are the same attachments as in my comment on Bug 353529.  As I wrote then:
With TBird on the PPC, MacMail on the Intel Mac, and Entourage on the Intel
Mac, the attachments had the same size when saved.  TBird on the Intel Mac
created files that were between 127 and 130 bytes larger.  The corresponding
application would report that these larger files were not of the correct
format.

The size of the files created with Thunderbird v3.0a2pre was the same too-large size as when created in Thunderbird 2.
I am not sure if I should list this as a new bug, but it seems related. I am using Mozilla Thunderbird version 2.0.0.14 (20080421). I am using Mac OS X 10.5.2 (Leopard), Intel-based dual core MacBook Pro.

I have a problem opening Microsoft Office files (.doc/.xls/.ppt) via double-click when they are sent as attachments. The application opens up ok, but there is a new blank doc/spreadsheet/presentation and not the file I clicked on.

If I "manually" open the file by saving it and doing File-->Open, there are no problems. I can read the file just fine. It's just that I can't double-click.

One more very strange thing: Whenever I double-click a file with the name "dftmpMKNOOFEMkkkkkkkk--------" (or some variation) is created. It is listed as being "Zero KB" in size. If I double-click on more than one attachment, a similar file is created, but it is 180 KB in size and is listed as "Plain Text" but does not open with TextEdit.

Any suggestions would be greatly appreciated.
PS: I am using Microsoft Office 2008, so this even happens with .docx, .xlsx and .pptx file. I have no problems with files whose default apps are not Office (pdfs, jpegs, txt, etc.)
Sorry for multiple emails. It seems this is an issue with Office 08 after the 5/14/08 SP1 update. See here: http://tinyurl.com/6rk99h
I think that given the state of this bug it's very unlikely to make a2.  resetting owner.
Assignee: mscott → nobody
Flags: wanted-thunderbird3.0a2? → wanted-thunderbird3.0a2-
Version: 2.0 → Trunk
Sounds like a libmime problem.  It'd be nice to handle it, especially as it seems to occur with common file formats like Office 08.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Summary: images I save from a certain message are corrupt, problems with AppleDouble encoded Macintosh files? → images I save from a certain message are corrupt, problems with AppleDouble encoded Macintosh and Office 08 files?
The nsAppleFileDecoder stream converter helper was apparently written assuming that the Mac would always be big endian.  On Intel Macs the header magic word test falls down, which is probably just as well as there is some other logic that would get tricked too.  The AppleDouble header gets passed through as a result, but that's not all that helpful because a third-party tool would likely expect an AppleSingle magic word and the data fork in its list of entries.

This is consistent with Mabry's reported observations.
Component: Mail Window Front End → Networking
Flags: wanted-thunderbird3.0a2-
Flags: blocking-thunderbird3+
Flags: blocking-thunderbird2-
Product: Thunderbird → Core
QA Contact: front-end → networking
Target Milestone: Thunderbird 3 → ---
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Attachment #340526 - Flags: review?(bzbarsky)
Thunderbird would like this for 1.9.1.
Flags: wanted1.9.1?
Summary: images I save from a certain message are corrupt, problems with AppleDouble encoded Macintosh and Office 08 files? → nsAppleFileDecoder assumes big-endian platform, effectively corrupts AppleDouble thunderbird mail attachments
Duplicate of this bug: 353529
Comment on attachment 340526 [details] [diff] [review]
use PR_ntohs/PR_ntohl to (potentially) swap things bigger than a byte

>+++ mozilla.0d05f2403712/netwerk/streamconv/src/nsAppleFileDecoder.cpp	2008-09-26 00:15:11.000000000 -0700
>+                m_dates.create = (SInt32)PR_ntohl((PRUint32)m_dates.create);
>+                m_dates.modify = (SInt32)PR_ntohl((PRUint32)m_dates.modify);
>+                m_dates.backup = (SInt32)PR_ntohl((PRUint32)m_dates.backup);
>+                m_dates.access = (SInt32)PR_ntohl((PRUint32)m_dates.access);
>+              }

You didn't cast the arguments in the first two blocks.  Be consistent about that?

Also, the results here should be cast to PRInt32, not SInt32.

With that, r+sr=bzbarsky
Attachment #340526 - Flags: review?(bzbarsky) → review+
Adding status whiteboard so the Thunderbird 3 folks can track core bugs we need.
Whiteboard: [tb3needs]
issues addressed, carrying forward r+sr=bzbarsky.  (Thanks for the quick review!)
Attachment #340526 - Attachment is obsolete: true
Attachment #340632 - Flags: superreview+
Attachment #340632 - Flags: review+
Keywords: checkin-needed
Comment on attachment 340632 [details] [diff] [review]
v2 use PR_ntohs/PR_ntohl to (potentially) swap things bigger than a byte
[Checkin: Comment 23]

http://hg.mozilla.org/mozilla-central/rev/fcfa9ee3c75f
Attachment #340632 - Attachment description: [to check-in] v2 use PR_ntohs/PR_ntohl to (potentially) swap things bigger than a byte → [to check-in] v2 use PR_ntohs/PR_ntohl to (potentially) swap things bigger than a byte [Checkin: Comment 23]
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
Attachment #340632 - Attachment description: [to check-in] v2 use PR_ntohs/PR_ntohl to (potentially) swap things bigger than a byte [Checkin: Comment 23] → v2 use PR_ntohs/PR_ntohl to (potentially) swap things bigger than a byte [Checkin: Comment 23]
Whiteboard: [tb3needs]
Flags: wanted1.9.1?
You need to log in before you can comment on or make changes to this bug.