589464 - Can't open or save QuarkXPress attachments - file extension qxp

Status: RESOLVED DUPLICATE of bug 579682

(MailNews Core :: MIME, defect)

Description

[Michael A. Pasek]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: [don't have, but can get if needed] Windows of some flavor, TB3.1.2

From the user (who I think explained it better than I could):
The attachment disappears as soon as I select the email (before the email is selected, you can see the paperclip, once you click on the email it vanishes and nothing appears in the attachment field when the email is fully opened either). However, when I hit the "forward" button it reappears in the attachment field, but if I double-click it at that point it crashes Thunderbird. It forwards just fine, but there seems to be no way to see it, save it or open it properly from within TB - I've used Thunderbird with Quark files for years now and have never seen anything like this until I installed the latest update. JPGs, DOC files, etc., all work fine. The problem seems confined to files with the QXP extension.

Reproducible: Always

Steps to Reproduce:
1. Receive an email with a QuarkXPress attachment
2 [review]. Click on the email in the Message List
3.
Actual Results:  
"Attachment" paper clip disappears, no attachment icon/filename in Message Pane/Tab/Window.  Additionally, attachment "reappears" in forwarded email, but cannot be opened (by sender).

Expected Results:  
1. "Attachment" icon (paper clip) in Message List should not have disappeared
2. The icon/filename should have been visible in the Message Pane/Tab/Window
3) The attachment should have been able to be saved or opened by a "helper" application.

Will add user's "mimeTypes.rdf" as attachment.  Deleting "mimeTypes.rdf" allowed the user to open the attachment.  The update is apparently doing something to the ".rdf" file, because this is the 3rd user I've seen that has had problems opening attachments of various types.  Two separate bugs have been filed for those cases (Bug 587660, Bug 587869).  ".qxp" entry in "mimeTYpes.rdf" shows MIME type of "application/appledouble" (on a Windows machine).  Actual MIME type in email is "application/octet-stream".  Sample emails from before/after upgrade are available via email upon request (privacy concerns), or headers can be added in a Comment if desired.

Depending on what's broken, the severity may need to be raised.

Comment 1

[Michael A. Pasek]

Attachment: mimeTypes.rdf

Comment 2

[James Yale]

Hi, 

Just to chime in and report that I'm seeing this bug as well with 3.1.2.

In my case the email appears in the inbox with the attachment icon but as soon as the email is clicked (to preview/open) the icon disappears and the loading indicator constantly spins (forever) - the email body is displayed straight away but never the attachment. 

The attachment can be recovered by forwarding the email (where it is displayed in the attachment list) and the icon restored by rebuilding the index of the mailbox. 

Should also point out that this client is connected to a Cyrus IMAP server (which may explain the infinite loading behaviour).

Comment 3

[Michael A. Pasek]

(In reply to comment #2)
> Just to chime in and report that I'm seeing this bug as well with 3.1.2.

Can you save a copy of your "mimeTypes.rdf" file, then delete the original and see if that corrects the problem ?  It may also be sufficient to just delete the entry (in Options/Preferences, Attachments) for the "qxp" file extension (but still save a copy of "mimeTypes.rdf", first).  If deleting either "mimeTypes.rdf" or the entry for the "qxp" file extension again allows correct handling of QuarkXPress attachments, please add your "mimeTypes.rdf" to the bug report as an attachment, and add a commend with your "Build Identifier" from "About Thunderbird" dialog.

Comment 4

[James Yale]

I should have been clearer with my initial comment - I'm getting the same symptoms as the reporter but in this particular case it's happening with a .eps file. It's also been reported to me that it happens with other file types (but I haven't witnessed this myself). I'd suggest this might be a wider issue than just .qxp files. 

To clarify:

Reproducible: Always with specific mail

Steps to Reproduce:
1. Receive an email with an attachment
2 [review]. Click on the email in the Message List
3.
Actual Results:  
"Attachment" paper clip disappears, no attachment icon/filename in Message
Pane/Tab/Window.  Additionally, attachment "reappears" in forwarded email.

Unfortunately Thunderbird seems to have updated this morning so it's one version newer than my last comment (not my system) but I can confirm the problem is still occuring.

I followed your suggestion to stop TB, delete the mimeTypes.rdf file and restart TB (I also then rebuild the folder index to restore the attachment icon in the message list) which didn't have any effect.

The problematic TB is on this version now:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3

Have uploaded the mimeTypes.rdf as requested. 

Thanks, 

Jim

Comment 5

[James Yale]

Attachment: mimeTypes from 3.1.3 - problem with attached .eps files

Comment 6

[Michael A. Pasek]

(In reply to comment #4)
> [...]  I'd suggest this might be a wider issue than just .qxp files. 

I think it is, too; see Bug 587660 and Bug 587869; there may be other bug reports that I don't know about.

> I followed your suggestion to stop TB, delete the mimeTypes.rdf file and
> restart TB (I also then rebuild the folder index to restore the attachment icon
> in the message list) which didn't have any effect.

The cause of your problem is not the same as that reported in this bug, since the "fix" that worked for that case didn't work for you.

> Have uploaded the mimeTypes.rdf as requested. 

That was only necessary if deleting "mimeTypes.rdf" or the entry for the (in your case) ".eps" file extension allowed the email to be properly processed -- which it didn't.

I'd suggest you open a new bug report that specifically refers to the ".eps" file extension (similar to this and the other two bugs mentioned).  I, too, believe they're all related, but I don't know why or how.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Sounds same problem as bug 579682.
(i) association of .XXX->multipart/appledouble exists in mimeTypes.rdf.
(ii) if .XXX is sent with Content-Type: application/octet-stream,
     it's impossible to open attached .XXX file.

Comment 8

[Michael A. Pasek]

(In reply to comment #7)
> Sounds same problem as bug 579682.
> (i) association of .XXX->multipart/appledouble exists in mimeTypes.rdf.
> (ii) if .XXX is sent with Content-Type: application/octet-stream,
>      it's impossible to open attached .XXX file.

Yes, it does sound like the same problem.  This bug's description ("application/appledouble") is incorrect; it should have stated "multipart/appledouble" as in bug 579682.

Why didn't the workaround (deleting mimeTypes.rdf) work for James Yale (Comment #4) ?

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> Why didn't the workaround (deleting mimeTypes.rdf) work for James Yale (Comment
> #4) ?

If workarund of bug 579682(deleting mimeTypes.rdf followed by restart of Tb, which does do deletion of multipart/appledouble related entries from mimeTypes.rdf) is really not effective, it's simply bacause that problem of comment #4 is different problem by different cause from this bug and bug 579682. It merely has same external symptom of "attachment icon disappears when mail is clicked". 

For next in comment #4.
> The problematic TB is on this version now:
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9.2.9) Gecko/20100825
Thunderbird/3.1.3
> Have uploaded the mimeTypes.rdf as requested. 
> mimeTypes from 3.1.3 - problem with attached .eps files

Following entry exists in attached mimeTypes.rdf. It produces problem of bug 579682 in Tb 3.0 or later, on attached .eps/.ps/.ai file, if file is sent with Content-Type: application/octet-stream.
> <RDF:Description RDF:about="urn:mimetype:multipart/appledouble" NC:value="multipart/appledouble" NC:editable="true" NC:description="Postscript File">
> <NC:fileExtensions>eps</NC:fileExtensions>
> <NC:fileExtensions>ps</NC:fileExtensions>
> <NC:fileExtensions>ai</NC:fileExtensions>
> <NC:handlerProp RDF:resource="urn:mimetype:handler:multipart/appledouble"/>
> </RDF:Description>

I don't think poster of comment #4 did do workaround of bug 579682 correctly on all Tb's profiles.

Comment 10

[Michael A. Pasek]

(In reply to comment #9)
> (In reply to comment #8)
> > Why didn't the workaround (deleting mimeTypes.rdf) work for James Yale (Comment
> > #4) ?
> [...]
> I don't think poster of comment #4 did do workaround of bug 579682 correctly on
> all Tb's profiles.

You may be correct, or this problem has aspects that may not be understood; the problem of "application/octet-stream" being equated to "multipart/appledouble" was (as you noted) reported in Bug 355142 -- but the effects have not been seen before now....why ?  Something else may be influencing these failures, in addition to the problem noted in Bug 355142.

Comment 11

[WADA:World Anti-bad-Duping Agency]

String of file extension itself is irrelevant to bug. "On which file extension bug 579682 occurs" depends on "For which file extension you did create mimeTypes entry for multipart/appledouble in the past".
Closing as DUP of bug 579682.

(In reply to comment #10)
> the problem of "application/octet-stream" being equated to "multipart/appledouble"
> was (as you noted) reported in Bug 355142
> -- but the effects have not been seen before now....why ?

"application/octet-stream" itself is irrelevant to bug 355142. "application/octet-stream" was merely one of conditions which invoked "Open dialog" by double click of attachment when bug was opened. See test mail and test procedure attached to bug 579682. 
"application/octet-stream" is relevant to "bug 579682(and this bug) after bug 355142".
Read bug 579682 comment #27, please.