456733 - PDF attachments are saved with incorrect creator and type codes

Status: NEW

(MailNews Core :: MIME, defect)

Description

[Etienne Miret]

User-Agent:       Firefox/3.0 Gecko/2008061004 (Macintosh; U; PPC Mac OS X 10.5; fr-FR; rv:1.9)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080922030535 Shredder/3.0b1pre

When Thuderbird saves a PDF file, it will set the creator code to 'CARO' and the type code to 'TEXT'. While the former could be correct, the latter is definitely wrong. 'CARO' is Acrobat’s creator code and 'TEXT' is the type code for plain text file.

The type code for PDFs is normaly 'PDF '. Additionally, I recommend not setting the creator code at all so that saved PDF will be open with the user’s default PDF viewer.


Reproducible: Always

Steps to Reproduce:
1. Select an email with a PDF attachment.
2. Saves the PDF attachment under any name, like "~/foo".
3. Open a Terminal window.
4. Run "GetFileInfo ~/foo". (GetFileInfo is a command-line utility installed under /Developer/usr/bin as part of the developer tools.)

Actual Results:  
The output of GetFileInfo will look like:
> type: "TEXT"
> creator: "CARO"
> attributes: avbstclinmedz
> created: 09/24/2008 14:15:09
> modified: 09/24/2008 14:15:09


Expected Results:  
The output of GetFileInfo should look like:
> type: "PDF "
> creator: ""
> attributes: avbstclinmedz
> created: 09/24/2008 14:15:09
> modified: 09/24/2008 14:15:09


On Mac OS files’ meta-data include a creator code and a type code. Those codes are 32 bits integers, but are usually written as four letter code, using ASCII equivalence.

The type code identifies the file type, just like MIME media types.

The creator code, unlike what the name reads, is the code of the application to use in order to open the file. If the creator code is set, it will override the default application that normally handles the file-type.

Comment 1

[Etienne Miret]

Attachment: Test case : email with 3 different PDF attachments

This email contains three PDF attachments:
 - first one is labelled as 'application/octet-stream' and has a '.pdf' filename
   extension,
 - second one is labelled as 'application/pdf' and has a '.pdf' filename
   extension.
 - third one is labelled as 'application/pdf' and has no filename extension.

Comment 2

[Nomis101]

I have tested this one.

First I created a PDF file with Adobe Acrobat 9 Pro (Mac OS X 10.5.6) and checked it with GetFileInfo before sending it. I get:

file: "/rektifikation.pdf"
type: "PDF "
creator: "CARO"
attributes: avbstclinmedz
created: 01/30/2009 01:33:22
modified: 01/30/2009 01:33:22

Than I've sendet the file to myself, received it with Thunderbird and saved it from Thunderbird to my hard drive. Than I checked it again with GetFileInfo. Now I get:

type: "PDF "
creator: "prvw"
attributes: avbstclinmedz
created: 01/30/2009 01:35:58
modified: 01/30/2009 01:35:58


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.2a1pre) Gecko/20090127 Thunderbird/3.1a1pre

Comment 3

[Ludovic Hirlimann [:Usul]]

(In reply to comment #1)
> Created an attachment (id=340120) [details]
> Test case : email with 3 different PDF attachments
> 
> This email contains three PDF attachments:
>  - first one is labelled as 'application/octet-stream' and has a '.pdf'
> filename

Etienne is this the only attachment that shows the issue (this looks like bug 453805). If not then this is a mime issue. I agree That the file Type should not be set to 'TEXT'.

Marking new based on the second comment. Again I think This is a dup - let me know If you don't think it is.

Comment 4

[Etienne Miret]

(In reply to comment #3)
> Etienne is this the only attachment that shows the issue (this looks like bug
> 453805).
Two things.

First, this is definitely not a duplicate of bug 453805. The later is about detecting the file type when the MIME type is not set. This bug is about a mapping from MIME type to MacOS type and creator codes.

Second, I must say I don’t know if there are other MIME types for which Thunderbird has an incorrect mapping into Mac codes. I have tested the mapping from image/png, image/jpeg and video/quicktime, which are all correct. But there are a lot of other file formats out there (although not all have a registered MIME type, or a known MacOS type).

If anyone knows which portion of the code is relevant to this mapping, I’d happily review it.

Comment 5

[Etienne Miret]

(In reply to comment #3)
> Etienne is this the only attachment that shows the issue (this looks like bug
> 453805). If not then this is a mime issue. I agree That the file Type should
> not be set to 'TEXT'.
It suddenly stroke me that I hadn’t understood your question. I’m feeling rather stupid right now...

So, the answer is *no*, the first attachment isn’t the only one that shows the issue. Actually, it is the only of the three that *does not* show the issue. It has a different issue, which is indeed bug 453805.

Since I now realize that many people here don’t have a Macintosh available to run the test case I’ve submitted, here’s the output, after all attachments from my email are saved to the disk:
> $ GetFileInfo octet-stream.pdf 
> file: "/Users/etienne/Desktop/octet-stream.pdf"
> type: "BINA"
> creator: "hDmp"
> attributes: avbstclinmedz
> created: 06/24/2009 20:37:46
> modified: 06/24/2009 20:37:46
> $ GetFileInfo PDF_with_extension.pdf 
> file: "/Users/etienne/Desktop/PDF_with_extension.pdf"
> type: "TEXT"
> creator: "CARO"
> attributes: avbstclinmedz
> created: 06/24/2009 20:37:46
> modified: 06/24/2009 20:37:46
> $ GetFileInfo PDF_without_extension 
> file: "/Users/etienne/Desktop/PDF_without_extension"
> type: "TEXT"
> creator: "CARO"
> attributes: avbstclinmedz
> created: 06/24/2009 20:37:46
> modified: 06/24/2009 20:37:46