Using build 20020131 on Mac OS9.1 an attachment (.doc,xls.ppt only ones tested at this time) with >31 characters will become corrupt when you Save as, Forward or Edit as New the mail message that has the attachment. 1. From a PC send an attachment (.doc or xls or ppt) with a long file name >31 characters). I created a simple .doc file with Word 2000 titled "Really long file name to send to a Mac". I then composed a message with very little text in body and attached that file, and sent it to myself. 2. I opened that message, double-clicked on the file to see if it was OK. It was. It opened word and text was readable. 3. I then did a context menu Save As. The saved file says it's a Netscape Document, opening it shows garbage on a Netscape page. 4. I then I did a Forward from the Mac and retrieved the Forwarded message, again corrupt and content type shows "text/plain; x-mac-type="54455854"; x-mac-creator="4D4F5353"; name="Really lon file name to send to a mac.doc"

nominating nsbeta, Time Inc people use mac and pcs to pass attachments back and forth and are running into this a lot.

setting qa contact to trix since attachment is getting corrupted.

putting the nsbeta in the keyword field.

A relevant fact is that for pre-OSX Macs, 31 chars is the max length for any file.

I understand that Mac OS has this max file length, but 4.7 was able to take this file and save or forward it with a truncated file name and not corrupt the file. I haven't checked Outlook yet. Note, 6.2 does truncate the file name, but it corrupts the file type in addition to truncating the name.

Note: Outlook Express on the same Mac OS 9.x can take this attachment with the long file name, save it,truncate the name and not corrupt the file itself. Forward with Outlook Express on the same Mac works too.

looking at it soon...

The data is not corrupted, only the type of the document is wrong therefore in open whith the wrong application which naturaly doesn't know how to interpret the data. The problem is caused by the fact that the document is saved without a file name extension (.doc), in that case because it has been truncated. You can reproduce the same problem if you send a word document named "sample" from Mac to Mac. Looks like we rae not using the content-type to determined the type of the file but only the extension. >4. I then I did a Forward from the Mac and retrieved the Forwarded message, >again corrupt and content type shows "text/plain; x-mac-type="54455854"; >x-mac-creator="4D4F5353"; name="Really lon file name to send to a mac.doc" I did a inline forward from my Mac and when I get the attachment on my PC, the name is correct (the full long version of it) and I can open it in Word. Esther, could you describe me the steps to reproduce the forward problem.

The current work around for this problem is to make sure you put the correct extension at the end of the file name when you save the attachment.

we have 2 problem here: 1) the file name should be nicely truncated before we show the save file dialog. nsILocal file nows how to truncate a file name without loosing the file extension. We should not have to do the truncation under MacOS X but currently, XPCOM file doesn't not support long file name. 2) We need to set the file application type and creator base on the content-type after the save and not let the OS do it for use based on the extension. I have a fix for both problem.

+#if defined (XP_MAC) + { + /* We need to truncate the name to 31 characters, this even on MacOS X until the file API Bad indentation. Are you using tabs?? + else + { + /* we need to set the correct application type and creator base on the content-type */ + nsCOMPtr<nsIInternetConfigService> icService (do_GetService(NS_INTERNETCONFIGSERVICE_CONTRACTID)); + if (icService) + { + PRBool asMapping; + if (NS_SUCCEEDED(icService-> HasMappingForMIMEType(m_contentType.get(), &asMapping)) && asMapping) ... Ditto. With this patch, do we ignore x-mac-type="54455854" x-mac-creator="4D4F5353" in the MIME info for the attachment, defaulting to what IC tells us? Or do we go first with this type/creator, and then fall back on IC iof it's not present?

>Bad indentation. Are you using tabs?? probably, I've just reinstalled my whole system from scratch and I am pretty sure I haven't changed the tab setting. I'll fix that before checkin >With this patch, do we ignore x-mac-type="54455854" x-mac-creator="4D4F5353" in >the MIME info for the attachment, defaulting to what IC tells us? Or do we go >first with this type/creator, and then fall back on IC iof it's not present? No, I am not using the attachment signature because mime does not provide it to the frant-end. This is a have discovered while working on this patch fo which I have decided to not do anything whith that (at least for now) because of the following reason: If user A send to user B a JPEG image created by a specific program. User B does not have that specific program but use another one to display image. If we use the application type/creator from the sender, we will have a file with no icon (but the user should stil be able to use it in that particular case but that might be not true in every case). However, using only the content-type, we are able to setup the file for the user B image application. If you reaaly think it's an issue, I'll file another bug for that.

This was an issue in the 4.x days too. The question is do you go with the sender's type/creator (which are known to be correct for the file), or do you rely on mime type/file extension and IC, which may assign an incorrect type/ creator to the file? In addition, what do you use when displaying the attachment icon in the message (if/when we use native icons there). It annoys me that 4.x shows CodeWarrior file attachments in the message window, but when I save them I get BBEdit files. This seems wrong. Also, bear in minde that on Mac OS X, there is no UI to allow the user to edit their IC-specified mime/extension mappings. I think your current patch is OK. Maybe we need input from UE folks on the type/ creator problem.

I don't know the frontend code for choosing an icon to display in the attachment pane but at it doesn't have the original file type and creator, my guess is that it 's base on the content-type and/or the extension using IC. I'll file a new bug for the type/creator issue. Does "I think your current patch is OK" means R=sfraser?

Comment on attachment 67941 [details] [diff] [review] Proposed fix, v1 r=sfraser

I've filled bug 123630 for the type/creator issue...

Comment on attachment 67941 [details] [diff] [review] Proposed fix, v1 I don't think you should be dealing directly with the internet config service here. I think you should be getting the nsIMIMEService and asking for the mime info for your content type. That Fill method on the internet config service is really a private interface that allows the mime service to talk to internet config. It does that work for you.

Same patch but this time using nsIMIMEInfo instead of the icService.

Comment on attachment 68157 [details] [diff] [review] Proposed fix, v2 sr=mscott

To answer Jean Francios question on 2-1, The message with the long file name without extension originally came from my PC using Word2000 amd NS6 build 2-4-2002. I forward this message inline while on Mac with 2-6 build back to myself. I then open the forwarded inline message when on the Mac 9.1 with 2-6trunk=the attachment shows garbage. I then open the forwarded inline message when on my PC with 2-4 trunk build - the attachment shows garbage. I know you're fixing this, just want to make sure you know more about the Forwarding portion of this problem.

Comment on attachment 68157 [details] [diff] [review] Proposed fix, v2 r=sfraser

I've checked in the fix v2. However more works is needed for the forwarding issue. While forwarding a long file name attachment, we are loosing the content-type! Ester, would you have a separate bug for the remaining issue?

All I did was removing the code that was trying to make a clean file name. This code was bogus and we were loosing the file extension of the attachment which is really the only piece of information we care about.

Comment on attachment 68252 [details] [diff] [review] Complementary patch for the forward issue, v1 r=cavin.

Comment on attachment 68252 [details] [diff] [review] Complementary patch for the forward issue, v1 sr=bienvenu

second patch checked in too. This is Fixed.

Using build 20020212 and the scenario listed this is fixed. Verified

Adding to status whiteboard AOLTW and plussing bugs definite requirements, adding just AOLTW for possibles.

Minusing