Closed Bug 309566 Opened 19 years ago Closed 15 years ago

when sending attachment with long or multibyte filename and receiver uses e.g. Outlook, the filename is changed to att00XXX.xxx (MS and some other clients still doesn't support RFC2231)

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: 13964001012, Assigned: masayuki)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: verified1.8.1.2)

Attachments

(1 file, 5 obsolete files)

Quirks patch rv3.0
8.04 KB, patch
mscott
: review+
mscott
: superreview+
mscott
: approval-thunderbird2+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050907 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050907 Firefox/1.4

send mail with  Chinese filename attachment
and resive by outlook express ,the filename is change
but the version 1.06 is not

Reproducible: Always

Steps to Reproduce:
1.send mail with  Chinese filename attachment
2 [review].resive by outlook express
3.the file name is change to att00XXX.xxx



Expected Results:  
like 1.06
Version: unspecified → 1.5
version : Thunderbird 1.5 Beta 1 (20050920)

I've got a similar problem 
attachement contains French accents and this is a long filename
receiver uses Outlook 2003
it sees the attachement with ATTxxxxx.xxx



It works with thunderbird 1.0.6

on the receiver side :
email sent with 1.0.6
This is a multi-part message in MIME format.
--------------060408000006080507070204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

--------------060408000006080507070204
Content-Type: application/msword;
 name="EB
=?ISO-8859-1?Q?detaill=E9e-Cyber-=5BONF=5D-=5BIH=5D-=5B5=2E46=5D-v=2E1?=
=?ISO-8859-1?Q?=2E0=2Edoc?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="EB
=?ISO-8859-1?Q?detaill=E9e-Cyber-=5BONF=5D-=5BIH=5D-=5B5=2E46=5D-v=2E1?=
=?ISO-8859-1?Q?=2E0=2Edoc?="

--------------060408000006080507070204--

same thing with thunderbird 1.5b1
This is a multi-part message in MIME format.
--------------020700030906050009090404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

--------------020700030906050009090404
Content-Type: application/msword;
 
name*0*=ISO-8859-1''EB%20detaill%E9e-Cyber-%5BONF%5D-%5BIH%5D-%5B5.46%5D
-v
 name*1*=.1.0.doc
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 
filename*0*=ISO-8859-1''EB%20detaill%E9e-Cyber-%5BONF%5D-%5BIH%5D-%5B5.4
6
 filename*1*=%5D-v.1.0.doc

--------------020700030906050009090404--

there's a big behaviour change between the two.
looks like Outlook 2003 doesn't like the way it's done with 1.5b1 (I don't know
if the format is valid or not)

It's a big pain
I'm reverting to 1.0.6 until it's fixed




Yes, same problem also exists in thunderbird 1.5b1, and mozilla 1.7 and before,
seamonkey(1.0a, 1.1a)!

when send mail(with a chinese filename attachment) with  mozilla 1.7, the
outlook cant auto detect the filename's encode. but the same mail send with
thunderbird 1.0.6, the outlook can audo display the filename properly! 

with thunderbird 1.5b1 and seamonkey, the same problem with is bug!

because many people use thunderbird and seamonkey(mozilla) must exchange info
with the user in windows environment,so it's a problem should been corrected as
soon as problem!
(In reply to comment #2)
> Yes, same problem also exists in thunderbird 1.5b1, and mozilla 1.7 and before,
> seamonkey(1.0a, 1.1a)!
> 
> when send mail(with a chinese filename attachment) with  mozilla 1.7, the
> outlook cant auto detect the filename's encode. but the same mail send with
> thunderbird 1.0.6, the outlook can audo display the filename properly! 
> 
> with thunderbird 1.5b1 and seamonkey, the same problem with is bug!
> 
> because many people use thunderbird and seamonkey(mozilla) must exchange info
> with the user in windows environment,so it's a problem should been corrected as
> soon as problem!

add some info:
  my locale is zh_CN.UTF-8, out mail encoding setting of thunderbird and
seamonkey is utf-8.

Can someone :
- change the bug summary to something more generic (for example : when sending
attachement with long filename and receiver uses Outlook, filename is changed to
att00XXX.xxx)
For international users, the filename contains extra encoding characters, which
make it artificially longer, and makes the bug worse.
- mark it as a regression (ie works for thunderbird 1.0, doesn't work
thunderbird 1.5b1) 
- change the status to NEW.

more testcases :
1.0 with short filename

This is a multi-part message in MIME format.
--------------040001020402040208010909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

test 1.0 short

--------------040001020402040208010909
Content-Type: text/plain;
 name="testtb1.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="testtb1.txt"

this is a test
--------------040001020402040208010909--

1.5 with short filename

This is a multi-part message in MIME format.
--------------050300000100020808070707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  test

--------------050300000100020808070707
Content-Type: text/plain;
 name="testtb1.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="testtb1.txt"

this is a test
--------------050300000100020808070707--


result :
1.0 and 1.5 with short filename behave the same -> OK

1.0 with long filename

This is a multi-part message in MIME format.
--------------060904020008040307030706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

test 1.0 long

--------------060904020008040307030706
Content-Type: text/plain;
 name="testverylongfilenameveryverylongreallythisisalongfilename.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="testverylongfilenameveryverylongreallythisisalongfilename.txt"

testl
--------------060904020008040307030706--

1.5 with long filename

This is a multi-part message in MIME format.
--------------010207070903070103020102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

test long

--------------010207070903070103020102
Content-Type: text/plain;
 name*0="testverylongfilenameveryverylongreallythisisalongfilename.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="testverylongfilenameveryverylongreallythisisalongfilename.tx";
 filename*1="t"

testl
--------------010207070903070103020102--

name of file : 61 characters, 60+1
result :
1.0 and 1.5 behave differently
1.5 format not understood by Outlook -> attxxxxx.xxx

1.0 with long filename (non ascii characters in filename)

This is a multi-part message in MIME format.
--------------070907020708050606060202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

test 1.0long2

--------------070907020708050606060202
Content-Type: text/plain;
 name="=?ISO-8859-1?Q?v=E9r=E0l=E9f=E0=E8_=E9ne=E0nonasciitestinside=2Etxt?="
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="=?ISO-8859-1?Q?v=E9r=E0l=E9f=E0=E8_=E9ne=E0nonasciitestinside=2Etxt?="


--------------070907020708050606060202--

1.5 with long filename (non ascii characters in filename)

This is a multi-part message in MIME format.
--------------080508000908020904070407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

test 1.5long2

--------------080508000908020904070407
Content-Type: text/plain;
 name*=ISO-8859-1''v%E9r%E0l%E9f%E0%E8%20%E9ne%E0nonasciitestinside.txt
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0*=ISO-8859-1''v%E9r%E0l%E9f%E0%E8%20%E9ne%E0nonasciitestinside.t
 filename*1*=xt


--------------080508000908020904070407--

name : 36 characters (seen by user) , 62 internally (60+2)
result :
1.0 and 1.5 behave differently
1.5 format not understood by Outlook -> attxxxxx.xxx


For English users, using ascii filenames, it is very rare to have a filename
which contains more than 60 characters.
For international users, the limit is very low as encoding adds to the size,
which explain why this occurs very often for Chinese, French, ....users

So, why did the format changed between 1.0 and 1.5 ?
Can the 1.0 format be restored as this is a regression from a user point of view ?
Flags: testcase+
We're following RFC 2231 to avoid long header lines - see bug 193439 for
details. Outlook should really know how to handle that.
in particular, you can set the pref "mail.strictly_mime_paramfolding" to 0 or 1
to get the old behaviour back
"mail.strictly_mime_paramfolding" should is mail.strictly_mime.parm_folding
It's really annoying. 

Could we change the default value of "mail.strictly_mime.parm_folding" to 0 or 1 so that the long-name attachment could be recognized by OE and Outlook which are still so widely used today.

I fully understand that developers want thunderbird to folow standards, and that for implementet an RFC 2231 compliant "send mail routine". I've read bug 193439, so wishing to revert to a state before this fix will not be successfull ;-)

I think the standard should be attended, but a workaround should be given. My proposal is folowing:

If a user attaches a file, that wil be corrupted (changing filename/extension meets this case for many users) by non RFC 2231 capable clients (such as outlook/express), TB should give a warning message, that informes the user about the possible problems, and eventually suggest to change the filename to a save one. This could look like this:

"Thunderbird has detected that the file you added, cannot be handled by non RFC 2231 e-mail programms, like outlook or outlook express. Shall Thunderbird convert the filename to a safe one? YES / NO"

With this function implemented, I think most users would not need to manipulate the prefs.js.
To all people that want developers to pay attention to this "bug", pleae vote for it!

PS: If someone could change the summary of this ID, because it is not an chinese only problem ;-)
FYI, I asked a friend working at MS, who informally asked internally about this. 
RFC2231 is not supported at this time in Outlook (all versions) (it is only supported in a few ms products or library). there's an internal RFE about this so may be this will be in future Outlook version.
A friend of mine was bitten by the same problem (Outlook users believe the problem is with the sender).
This is going to be a big problem for all international thunderbird 1.5 users.
I understand that thunderbird is willing to respect standards but I still think something should really be done on thunderbird side. (ie like the strict and quirks mode in firefox so that thunderbird just works out of the box)
Solutions may be to :
- disable rfc2231 encoding by default
- disable rfc2231 encoding for international builds only
- add a warning as mentionned before sending the email and allow the user to revert the mail to pre-rfc2231 behavior
- allow the pref to be set/unset in the preference window (editing a file is not really user friendly..)
...
Summary: when send a mail with Chinese filename attachment ,and resive by outlook the filename is changeto att00XXX.xxx → when sending attachement with long filename and receiver uses Outlook, filename is changed to att00XXX.xxx or when sending a mail with Chinese filename attachment ,and resive by outlook the filename is changeto att00XXX.xxx
Status: UNCONFIRMED → NEW
Ever confirmed: true
Good to hear that MS is willing to fix their problem. It may have been premature to switch, but I guess we have enough clout now to put some pressure on those who don't respect the standard. Anyway, those who wanna give in can do that as explained in comment #7 and comment #8. If you like to do it more easily, you can install 'about:config' extension for Thunderbird (http://aboutconfig.mozdev.org/ ). With the extension installed, you can easily change the preference value.

Perhaps, it's a good idea to add this to the release notes of TB 1.5. 



IMHO, "normal Users" don't read documentations, specially if it is something "as trivial" as a mail client. So relaying on this is IMHO not a good idea...

Beside this, it seems that Mozilla thinks it is time to make Thunderbird even more standard-conform, we should support this, not asking ourself how we switch of the new "feature".

The user dialogue I mentioned above, informs the user that he uses an "advanced Mail-Client", and that the "problem" is not with it, but with the Microsoft apps (for example). More important, it informs the user "When it is needed" not weeks ago when he (what I don't believe) reads the Release Notes...
*** Bug 321204 has been marked as a duplicate of this bug. ***
*** Bug 321207 has been marked as a duplicate of this bug. ***
FYI: We at Mozilla Japan team released the patch as an extension that changes the value of "mail.strictly_mime_paramfolding" to 0.

http://www.mozilla-japan.org/kb/solution/3067
http://www.mozilla-japan.org/products/thunderbird/patches/309566.xpi
Summary: when sending attachement with long filename and receiver uses Outlook, filename is changed to att00XXX.xxx or when sending a mail with Chinese filename attachment ,and resive by outlook the filename is changeto att00XXX.xxx → when sending attachement with long filename (especially multibyte characters) and receiver uses Outlook, the filename is changed to att00XXX.xxx
(In reply to comment #17)
> FYI: We at Mozilla Japan team released the patch as an extension that changes
> the value of "mail.strictly_mime_paramfolding" to 0.

Typo. I meant "mail.strictly_mime.parm_folding".

All/All because this problem could be reproduced on other MUA.
OS: Windows XP → All
Hardware: PC → All
Is this bug enhancement that the default setting should be changed?
If so, I think that this should be marked to INVA or WONTFIX.
This makes trouble for legacy MUA. This is a serious issue for marketing. But if we change the default settings now, we may never re-change to current settings. We should not change this settings for standardization.
I filled two RFE related to this bug :
bug 323388 to expose the preference in the option window
bug 323390 to warn users at composition time 
PLEASE: All who think that the "warning dialog" solution is the way to go, please vote for it in bug 323390...
The same problem occurs with short (and long) filenames using non-ASCII letters (ISO 8859-1, etc.).

https://bugzilla.mozilla.org/show_bug.cgi?id=317972
same bug, looks at comment 5 (test 1.5 with long filename (non ascii characters in filename))
BTW: the about:config extension isn't necessary to change the pref. Thunderbird 1.5 provides this config in Tools > Options... > Advanced > General

Providing the german Thunderbird support forums, I can confirm users don't read documentation including release notes. A confirmation dialog could be the solution. I believe there are so many other incompatibilities we could/should have confirm dialogs for, so this would be annoying.

What about a new tab in options dialog, where we could have some compatibility options?
*** Bug 317972 has been marked as a duplicate of this bug. ***
Blocks: 305650
Blocks: 314116
Depends on: 323390
Depends on: 323388
Blocks: 193439
*** Bug 305650 has been marked as a duplicate of this bug. ***
*** Bug 314116 has been marked as a duplicate of this bug. ***
I think we should wait for Office 17 (Outlook) and Vista (Windows Mail, formerly Outlook Express) to be released although we don't know MS team will support RFC 2231 or not. Mozilla team must be able to talk about this issue.
Summary: when sending attachement with long filename (especially multibyte characters) and receiver uses Outlook, the filename is changed to att00XXX.xxx → when sending attachement with long or multibyte filename and receiver uses Outlook, the filename is changed to att00XXX.xxx
(In reply to comment #28)
> I think we should wait for Office 17 (Outlook)

No... Of course Office *12*.
Problem confirmed with QUALCOMM Windows Eudora Version 6.1.1.1, when sending a 58 character long .pdf. The attachent name is rendered truncated. I just made a fool out of myself when a bunch of clients could not read my proposal... not very professional.

Guys, we have all the Outlook and Eurora users receiving long named attachments incorrectly.

Lets consider resetting the default of "mail.strictly_mime_paramfolding" for compatibility reasons until other mailers adhere to the standard. 
*** Bug 325212 has been marked as a duplicate of this bug. ***
Hi all,

One more reason to reset the default value of "mail.strictly_mime.parm_folding" to 0: even if the receiver does not use outlook or eudora or any other client but uses the webmail interface (e.g yahoo.com) the problem is there.

To reproduce, with TB 1.5 default setting (mail....=2) and a yahoo account, sent yourself a file with accents in the name (e.g jérôme_eymann_l11.doc). Once received, try to read it in TB, it will look OK, but try to use Firefox (or IE or whtever you want) instead, login to your yahoo account, open the mail, it will show attach1.bin or something like that and you will not be able to read it. 

You can reproduce this problem with hotmail as well. gmail is a bit smarter, i.e you will be able to read the file - but even in this one it will not look clean as the file name will have been signifcantly modified.

Cheers
*** Bug 326265 has been marked as a duplicate of this bug. ***
*** Bug 326384 has been marked as a duplicate of this bug. ***
Some additional information may be helpful in resolving this issue.

Our issue is that if we try to send an open file (say I have a file open in excel) and use the excel menu FILE: SEND TO: Mail Recipient as attachment. The file appears differently between different mail recipients. If the recipient uses Thunderbird they see it as an *.XLS.  If the recipient uses MS Outlook, they see it as a *.dat file.

After reading through some of the bugs related to this issue and closely related issues....

Apparently, Thunderbird seems to be sending the program's temp file if the file is open by the respective program.  While other Thunderbird cliets recognize this (tested with sending TB build 1.5 to Receiving TB build 1.0) and appropriately identifies the extension to open the file.

The work around for this that seems to work is this.  Save and close the file, then exit out of the program (ie Excel) and either send from explorer or create a new email and attach the file.

Writing a new email and attaching the file via TB will also result in a *.dat file being sent if the file is open by another program.

While this is inconvenient, it is not impossible to overcome.

I hope that this information will help narrow down the list of possibilities as to what needs to be fixed.

Yes, this is repeatable, as I had another person verify that sending the file with it open by another program yielded similar results (TB 1.5 excel file showed up as a *.dat and TB 1.0 file showed up as *.tmp.

If you need more information to help resolve this please email me.  If I filed this under the wrong bug, please forgive me.  I am still a little new to Mozilla software/etc...
(In reply to comment #35)

> Yes, this is repeatable, as I had another person verify that sending the file
> with it open by another program yielded similar results (TB 1.5 excel file
> showed up as a *.dat and TB 1.0 file showed up as *.tmp.

Your issue is not relevant here. Would you please file a new bug on the issue and note it here?
 
(In reply to comment #32)

> One more reason to reset the default value of "mail.strictly_mime.parm_folding"
> to 0: even if the receiver does not use outlook or eudora or any other client
> but uses the webmail interface (e.g yahoo.com) the problem is there.

It'll also be nice if you write to them to fix their programs. What's the beauty of a web-based service? If it's fixed at the server, it's 'propogated' instantly.


> You can reproduce this problem with hotmail as well. gmail is a bit smarter,
> i.e you will be able to read the file - but even in this one it will not look
> clean as the file name will have been signifcantly modified.

I've already written to gmail about this and they promised that they'd fix it before long. 

Removing Bug 305650 and Bug 314116 from "blocks:" because they are already DUPed to this bug.

By the way, it looks for me that clear description in "Release Notes" is sufficient for many users.
 [Compatibility]
   [Mail attachment's filename]
    We've stopped mal-use of RFC2047 in name/filename parameter.
    We use RFC2231 correctly from now on for name/filename parameter,
    based on IETF's RFC.
    However, some old mail clients maybe doesn't support RFC2231 correctly.
    For example, MS Outlook family, Eudora, Lotus Notes, some Mobile phones
    and some Web mails.
    For compatibility with such old mailers, we have an option to fall back to
    mal-use of RFC2047 for name/filename parameter.
    - Set mail.strictly_mime.parm_folding to 0 thru config editor.
    To get back to no mal-use of RFC2047 again,
    change mail.strictly_mime.parm_folding back to 2 thru config editor.
    See Bug 193439 and Bug 309566 for detail.
(But I also believe Bug 323388 & Bug 323390 are very kind for users and are required.)
No longer blocks: 305650, 314116
Yes, I met same problem. Our company use Exchage email server. When I send attachment with Chinese character filename, every one (using outlook) who received my email will see the attached file name "ATTxxxxxx.xxx". some time the extension part of the attached file will be seen as "dat".

The same problem also found in the latest Mozilla application suit.

So I just go back to thunderbird 1.0.7, it's ok for me.
Hello dew9034@comcast.net,

The ATT*.dat file is created by Outlook, not TB or Excel.  The problem you are experiencing is due to the fact that Excel's temporary files almost always go into a folder with a very long path (e.g. C:\Document and Settings\MyUserName\Application Data\Microsoft\Office\....) and TB correctly uses the new RFC2231 instead of the "defunct" RFC2047.  

To fix your problem use the following configuration setting:

pref("mail.strictly_mime.parm_folding", 0); 

-- John

http://e-numera.com/
http://ajax-web2.com/

(In reply to comment #35 -- snipped for brevity)
> Our issue is that if we try to send an open file (say I have a file open in
> excel) and use the excel menu FILE: SEND TO: Mail Recipient as attachment. The
> file appears differently between different mail recipients. If the recipient
> uses Thunderbird they see it as an *.XLS.  If the recipient uses MS Outlook,
> they see it as a *.dat file.
>
> Apparently, Thunderbird seems to be sending the program's temp file if the file
> is open by the respective program.  While other Thunderbird cliets recognize
> this (tested with sending TB build 1.5 to Receiving TB build 1.0) and
> appropriately identifies the extension to open the file.
> 


(In reply to comment #37)

> By the way, it looks for me that clear description in "Release Notes" is
> sufficient for many users.

WADA, will you please file a new bug on this? Although not many users read "Release Notes", it'll be 'read' by web robots and google and other search engines will make it easy to find. Moreover, some thunderbird support pages will pick it up as well raising the chance of it being available to end-users even higher.

BTW, two largest web mail service providers in Korea (Naver and Hanmail.net) promised that they'd fix the bug(i.e. would support RFC 2231) sooner or later in response to my bug report. Gmail will do that, too. It'd be nice if you contact major web mail service providers in your countries to support RFC 2231.
Hi All,

I have been able to test this issue in Outlook 12 Pre Release and they have not implemented RFC 2231 into there product from the face of it. I am unable to find any new options to enable this to change the way they encode the attachment name.
Some of e-mail clients ("TheBat!" for example) also rename the attachments with non-ASCII filename sent by thunderbird. I think this happened because the Thunderbird encodes filename like this:

filename*=koi8-r''%E3%C5%CE%CF%D7%CF%CA%20%CC%C9%D3%D4%202006-03-18.doc

and other e-mail clients - like this:

filename="=?koi8-r?B?79DSz9Nf0NPJyMbBy18wNjAzMDkucnRm?="
*** Bug 340200 has been marked as a duplicate of this bug. ***
*** Bug 340819 has been marked as a duplicate of this bug. ***
*** Bug 343226 has been marked as a duplicate of this bug. ***
*** Bug 347749 has been marked as a duplicate of this bug. ***
*** Bug 348064 has been marked as a duplicate of this bug. ***
Summary: when sending attachement with long or multibyte filename and receiver uses Outlook, the filename is changed to att00XXX.xxx → when sending attachement with long or multibyte filename and receiver uses Outlook, the filename is changed to att00XXX.xxx (MS still doesn't support RFC2231)
*** Bug 348800 has been marked as a duplicate of this bug. ***
(In reply to comment #40)
> WADA, will you please file a new bug on this?
Jshin, I've opened Bug 348821. Sorry for late open.
>Please describe about new "RFC2331 compliance" and "how to fall back to mal-use
>of RFC2047" in "Release Notes", in order to avoid more DUPs of Bug 309566
Often arrives with autocad and word files
*** Bug 354292 has been marked as a duplicate of this bug. ***
*** Bug 357817 has been marked as a duplicate of this bug. ***
*** Bug 360676 has been marked as a duplicate of this bug. ***
*** Bug 360676 has been marked as a duplicate of this bug. ***
*** Bug 360842 has been marked as a duplicate of this bug. ***
*** Bug 362821 has been marked as a duplicate of this bug. ***
*** Bug 324942 has been marked as a duplicate of this bug. ***
*** Bug 364295 has been marked as a duplicate of this bug. ***
This is perhaps slightly off-topic, but the issue with Outlook/OE has in fact been filed as a bug with Microsoft, per this amusing account:
  <http://weblog.timaltman.com/node/834>

The next version of OE is scheduled for release simultaneously with Vista.  Whether this problem is addressed or not, we'll find out then.
(In reply to comment #60)
> This is perhaps slightly off-topic, but the issue with Outlook/OE has in fact
> been filed as a bug with Microsoft, per this amusing account:
>   <http://weblog.timaltman.com/node/834>
> 
> The next version of OE is scheduled for release simultaneously with Vista. 
> Whether this problem is addressed or not, we'll find out then.
> 

Sigh.

I just tested this with RTM Outlook 2007 on WinXP (32 bit). It appears that folded names work.....if they are not "too long"! Outlook still breaks if the filename is more than around 125 characters. It looks like the attachement's filename is truncated at that point. Sheeesh.

OE is called "Mail" in Vista. A POP3 user could check this out already, using RTM Vista.
URL: http://kb.mozillazine.org/Attachments...
QA Contact: general → attachments
Summary: when sending attachement with long or multibyte filename and receiver uses Outlook, the filename is changed to att00XXX.xxx (MS still doesn't support RFC2231) → when sending attachment with long or multibyte filename and receiver uses e.g. Outlook, the filename is changed to att00XXX.xxx (MS and some other clients still doesn't support RFC2231)
Version: 1.5 → Trunk
The same behaviour with ThunderBird 2 beta 2. Should anybody add this bug as a blocker for release?
Flags: blocking-thunderbird2?
Attached patch Quirks patch rv.1.0 (obsolete) — — Splinter Review 
This is a quirks patch.

1. the name param uses RFC 2047 style in default setting.
2. the RFC 2047 style cannot separate the line in the standard behavior, therefore, it's not separate the line if over 998 characters(limit of RFC).
3. the name param is not outputted at using strict mode that is current trunk setting.

We should take this for compatibility for other MUAs. I confirm that this patch works fine for OE. But the cellular phone of au doesn't work fine if the file name is long. Mozilla Japan should contact to au...
Assignee: mscott → masayuki
Status: NEW → ASSIGNED
Attachment #255059 - Flags: superreview?(mscott)
Attachment #255059 - Flags: review?(mscott)
Attached patch Quirks patch rv.1.1 (obsolete) — — Splinter Review 
Oops, sorry the file is wrong.(old version)
Attachment #255059 - Attachment is obsolete: true
Attachment #255060 - Flags: superreview?(mscott)
Attachment #255060 - Flags: review?(mscott)
Attachment #255059 - Flags: superreview?(mscott)
Attachment #255059 - Flags: review?(mscott)
(In reply to comment #67)
> But the cellular phone of au doesn't work fine if the file
> name is long. Mozilla Japan should contact to au...

Ah, sorry. The problem of au is occurred on old style too. It's not the new issue.
Attached patch Quirks patch rv.1.2 (obsolete) — — Splinter Review 
fix a bug for the setting is '1' or '4'.
Attachment #255060 - Attachment is obsolete: true
Attachment #255067 - Flags: superreview?(mscott)
Attachment #255067 - Flags: review?(mscott)
Attachment #255060 - Flags: superreview?(mscott)
Attachment #255060 - Flags: review?(mscott)
+      PRInt32 len =
+        parmFolding == 0 ? MAX_LINE_LENGTH : kMIME_ENCODED_WORD_SIZE;
+      encodedRealName = RFC2047ParmFolding(charset, nsnull, real_name, len);
Sorry, I didn't realize this would violate RFC 2047.
A single encoded-word cannot exceed 75 characters.
http://www.ietf.org/rfc/rfc2047.txt
>   An 'encoded-word' may not be more than 75 characters long, including
>   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
>   desirable to encode more text than will fit in an 'encoded-word' of
>   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
>   be used.
We can't use CRLF in the paramter. So we have no way to represent the file name longer than 75 characters.

Of course, we will violate RFC2047 anyway.
>   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.
>   + An 'encoded-word' MUST NOT be used in parameter of a MIME
>     Content-Type or Content-Disposition field, or in any structured
>     field body except within a 'comment' or 'phrase'.
Even so, I think we should avoid using 'pseduo' encoded-word longer than 72 characters which may introduce new interoperability problems.
(In reply to comment #71)
> +      PRInt32 len =
> +        parmFolding == 0 ? MAX_LINE_LENGTH : kMIME_ENCODED_WORD_SIZE;
> +      encodedRealName = RFC2047ParmFolding(charset, nsnull, real_name, len);
> Sorry, I didn't realize this would violate RFC 2047.
> A single encoded-word cannot exceed 75 characters.
> http://www.ietf.org/rfc/rfc2047.txt
> >   An 'encoded-word' may not be more than 75 characters long, including
> >   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
> >   desirable to encode more text than will fit in an 'encoded-word' of
> >   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
> >   be used.
> We can't use CRLF in the paramter. So we have no way to represent the file name
> longer than 75 characters.

Thanks. I think that we have another way. We can shrink the file name in name param.
Comment on attachment 255067 [details] [diff] [review]
Quirks patch rv.1.2

I'll attach another approach.
Attachment #255067 - Flags: superreview?(mscott)
Attachment #255067 - Flags: review?(mscott)
Attachment #255067 - Flags: review-
Attached patch Quirks patch rv.2.0 (obsolete) — — Splinter Review 
This patch shrinks the file name for name field at '3'.

First time, the patch tries to keep the extension at shrinking. But if it failed, the patch cuts the tail of file name (including extension).

So, the RFC 2231 style encoding unsupported MUA cannot recover the original long file name if the file name is too long.
Attachment #255099 - Flags: superreview?(mscott)
Attachment #255099 - Flags: review?(mscott)
Attachment #255067 - Attachment is obsolete: true
Attached patch Quirks patch rv.2.0.1 (obsolete) — — Splinter Review 
fix a nit.
Attachment #255099 - Attachment is obsolete: true
Attachment #255101 - Flags: superreview?(mscott)
Attachment #255101 - Flags: review?(mscott)
Attachment #255099 - Flags: superreview?(mscott)
Attachment #255099 - Flags: review?(mscott)
test results:

1. OE and au cellular phones use name param. Therefore, the file names are shrunk.
2. Gmail and Becky use name param. Therefore, the file names are shrunk. But if '2', they can use filename param, so they can show the original names.
3. Mac Mail uses file name param. so, there are no problem.

I think that for case 2, the MUAs should use filaname param if both params are.
From the patch:
+// Note that when 1 or 4, it is separate the value to two or more lines if the line is too long,
+// but the thing is *not* standard-compliant. Because the  RFC 2045 doesn't allow
+// the separation in a value.

suggested rewording:
// Note that with 1 or 4, a long 'name' will cause the Content-Type header to
// be folded; this is not standard-compliant behavior, as RFC 2045 prohibits
// folding within a value.

However: I couldn't actually find a prohibition against that, do you have a pointer?  Or did you mean RFC 2047?  (If so, that rewording is not accurate.)


(In reply to comment #76)
> test results:
> 
> 1. OE and au cellular phones use name param. Therefore, the file names are
>    shrunk.
> 2. Gmail and Becky use name param. Therefore, the file names are shrunk. But
>    if '2', they can use filename param, so they can show the original names.
> 3. Mac Mail uses file name param. so, there are no problem.

Test results aren't too useful if you don't say what you did to generate those results.  I'm guessing that what you've done here is sent messages using various values for param_folding -- which values did you use, for which MUAs? 

The if/therefore statement in #1 isn't logically correct -- maybe you meant, "therefore, use file-name shrinking when sending to these MUAs" (?)  

Also, which version of OE are you testing against?  The OE replacement with Vista, "Mail," supports RFC2331, but per comment 61, in imposes a limit on the filename length even with 2331-encoding.


> I think that for case 2, the MUAs should use filaname param if both params
> are.

Well, MUAs *should* be following RFC 2331 without problems.

Could you post some examples of how the headers would actually appear for various filenames?  Maybe one short Japanese file name, one long Japanese file name, and one long ASCII filename?  It's not clear to me how the shortened names are going to appear.
(In reply to comment #77)
> suggested rewording:

thanks, I'll replace in next patch. (or before checking-in.)

> However: I couldn't actually find a prohibition against that, do you have a
> pointer?  Or did you mean RFC 2047?  (If so, that rewording is not accurate.)

Oops, that is RFC 2047 now. (see comment 71.)

> The if/therefore statement in #1 isn't logically correct -- maybe you meant,
> "therefore, use file-name shrinking when sending to these MUAs" (?)  

Ah, not so. I meant that the MUAs displays the filenames as shrunk name.

> Also, which version of OE are you testing against?

I tested with OE6(6.00.2900.2180) on XP SP2.

> Could you post some examples of how the headers would actually appear for
> various filenames?  Maybe one short Japanese file name, one long Japanese file
> name, and one long ASCII filename?  It's not clear to me how the shortened
> names are going to appear.

simple Japanese testcases:
1. テストファイルテストファイルテストファイルテストファイルテストファイル.txt
 name="=?ISO-2022-JP?B?GyRCJUYlOSVIJVUlISUkJWsbKEIudHh0?="

 filename*0*=ISO-2022-JP''%1B%24%42%25%46%25%39%25%48%25%55%25%21%25%24%25;
 filename*1*=%6B%1B%28%42%2E%74%78%74

OE displays "テストファイルテストファイル.txt"

2. テストファイル.txtテストファイルテストファイルテストファイルテストファイルテストファイルテストファイル
 name="=?ISO-2022-JP?B?GyRCJUYlOSVIJVUlISUkJWsbKEIudHh0GyRCJUYlOSVIJVUbKEI=?="

 filename*0*=ISO-2022-JP''%1B%24%42%25%46%25%39%25%48%25%55%25%21%25%24%25;
 filename*1*=%6B%1B%28%42%2E%74%78%74%1B%24%42%25%46%25%39%25%48%25%55%25;
 filename*2*=%21%25%24%25%6B%25%46%25%39%25%48%25%55%25%21%25%24%25%6B%25;
 filename*3*=%46%25%39%25%48%25%55%25%21%25%24%25%6B%25%46%25%39%25%48%25;
 filename*4*=%55%25%21%25%24%25%6B%25%46%25%39%25%48%25%55%25%21%25%24%25;
 filename*5*=%6B%25%46%25%39%25%48%25%55%25%21%25%24%25%6B%1B%28%42

OE displays "テストファイル.txtテストフ"

3. テストファイル.txt
 name="=?ISO-2022-JP?B?GyRCJUYlOSVIJVUlISUkJWsbKEIudHh0?="

 filename*0*=ISO-2022-JP''%1B%24%42%25%46%25%39%25%48%25%55%25%21%25%24%25;
 filename*1*=%6B%1B%28%42%2E%74%78%74

OE displays "テストファイル.txt"

I'll test with ASCII long name.
testfile.txttestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfiletestfile

I tested the ASCII long name. But it's NG.(the name param value is not shrunk name.) I'll attach a new file.
(In reply to comment #78)
> > Or did you mean RFC 2047?  (If so, that rewording is not accurate.)
> 
> Oops, that is RFC 2047 now. (see comment 71.)

OK -- I think that you can, in fact, fold a header using RFC 2047.  You need to break the text into small enough chunks that they can be MIME-encoded while still fitting in the 75-character limit, but you'd see something like:
  name="=?ISO-2022-JP?B?GyRCJUYlOSV....?=
   =?ISO-2022-JP?B?....CJUYlOSVIJVUbKEI=?="
Per RFC 2047, whitespace between MIME-encoded atoms is ignored.


> > The if/therefore statement in #1 isn't logically correct -- maybe you meant,
> > "therefore, use file-name shrinking when sending to these MUAs" (?)  
> 
> Ah, not so. I meant that the MUAs displays the filenames as shrunk name.

... when they receive a message formatted using option 3, right?
(In reply to comment #80)
> (In reply to comment #78)
> > > Or did you mean RFC 2047?  (If so, that rewording is not accurate.)
> > 
> > Oops, that is RFC 2047 now. (see comment 71.)
> 
> OK -- I think that you can, in fact, fold a header using RFC 2047.  You need to
> break the text into small enough chunks that they can be MIME-encoded while
> still fitting in the 75-character limit, but you'd see something like:
>   name="=?ISO-2022-JP?B?GyRCJUYlOSV....?=
>    =?ISO-2022-JP?B?....CJUYlOSVIJVUbKEI=?="
> Per RFC 2047, whitespace between MIME-encoded atoms is ignored.

Ah, sorry. RFC 2045 said:

> parameter := attribute "=" value
> value := token / quoted-string
> token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>          or tspecials>

we cannot include the white spaces in parameter value.

> > > The if/therefore statement in #1 isn't logically correct -- maybe you meant,
> > > "therefore, use file-name shrinking when sending to these MUAs" (?)  
> > 
> > Ah, not so. I meant that the MUAs displays the filenames as shrunk name.
> 
> ... when they receive a message formatted using option 3, right?

yes.
(In reply to comment #81)
> (In reply to comment #80)
> > (In reply to comment #78)
> > > > Or did you mean RFC 2047?  (If so, that rewording is not accurate.)
> > > 
> > > Oops, that is RFC 2047 now. (see comment 71.)
> > 
> > OK -- I think that you can, in fact, fold a header using RFC 2047.  You need to
> > break the text into small enough chunks that they can be MIME-encoded while
> > still fitting in the 75-character limit, but you'd see something like:
> >   name="=?ISO-2022-JP?B?GyRCJUYlOSV....?=
> >    =?ISO-2022-JP?B?....CJUYlOSVIJVUbKEI=?="
> > Per RFC 2047, whitespace between MIME-encoded atoms is ignored.
> 
> Ah, sorry. RFC 2045 said:
> 
> > parameter := attribute "=" value
> > value := token / quoted-string
> > token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
> >          or tspecials>
> 
> we cannot include the white spaces in parameter value.

Sigh, I'm confusing. Sorry.
You said that the quoted-string can contain the white spaces?
(In reply to comment #82)
> > > Per RFC 2047, whitespace between MIME-encoded atoms is ignored.
> > 
> > Ah, sorry. RFC 2045 said:
> > 
> > > parameter := attribute "=" value
> > > value := token / quoted-string
> > > token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
> > >          or tspecials>
> > 
> > we cannot include the white spaces in parameter value.
>
> Sigh, I'm confusing. Sorry.
> You said that the quoted-string can contain the white spaces?

That's not what I was originally saying, but yes: quoted-string *can* contain whitespaces -- that's from RFC 2822.


Is there any difference between param_folding=0 vs 1, or 3 vs 4, other than the shortened name?
(In reply to comment #83)
> (In reply to comment #82)
> > > > Per RFC 2047, whitespace between MIME-encoded atoms is ignored.
> > > 
> > > Ah, sorry. RFC 2045 said:
> > > 
> > > > parameter := attribute "=" value
> > > > value := token / quoted-string
> > > > token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
> > > >          or tspecials>
> > > 
> > > we cannot include the white spaces in parameter value.
> >
> > Sigh, I'm confusing. Sorry.
> > You said that the quoted-string can contain the white spaces?
> 
> That's not what I was originally saying, but yes: quoted-string *can* contain
> whitespaces -- that's from RFC 2822.

I think that RFC 2822 is a newer spec than RFC 2045. If so, the old MUAs cannot resolve the quoted string that has whitespaces?

> Is there any difference between param_folding=0 vs 1, or 3 vs 4, other than the
> shortened name?

nothing.
Attachment #255101 - Flags: superreview?(mscott)
Attachment #255101 - Flags: review?(mscott)
(In reply to comment #83)
> That's not what I was originally saying, but yes: quoted-string *can* contain
> whitespaces -- that's from RFC 2822.
quoted-string can contain whitespaces *except* CR LF sequence.
http://www.ietf.org/rfc/rfc2822.txt
>quoted-string   =       [CFWS]
>                        DQUOTE *([FWS] qcontent) [FWS] DQUOTE
>                        [CFWS]
>qcontent        =       qtext / quoted-pair
>qtext           =       NO-WS-CTL /     ; Non white space controls
>                        %d33 /          ; The rest of the US-ASCII
>                        %d35-91 /       ;  characters not including "\"
>                        %d93-126        ;  or the quote character
>NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
>                        %d11 /          ;  that do not include the
>                        %d12 /          ;  carriage return, line feed,
>                        %d14-31 /       ;  and white space characters
>                        %d127
>quoted-pair     =       ("\" text) / obs-qp
>text            =       %d1-9 /         ; Characters excluding CR and LF
>                        %d11 /
>                        %d12 /
>                        %d14-127 /
>                        obs-text
>obs-qp          =       "\" (%d0-127)
>obs-text        =       *LF *CR *(obs-char *LF *CR)
>obs-char        =       %d0-9 / %d11 /          ; %d0-127 except CR and
>                        %d12 / %d14-127         ;  LF
It can contain bare CR / bare LF only for compatibility with RFC 822, but it's useless here. It cannot contain CR LF sequence without adding "\" before each characters.

(In reply to comment #80)
>   name="=?ISO-2022-JP?B?GyRCJUYlOSV....?=
>    =?ISO-2022-JP?B?....CJUYlOSVIJVUbKEI=?="
Therefore, it's not allowed per RFC 2045/2822.
Sorry, I missed the folding white space. Please ignore the previous comment.
> FWS             =       ([*WSP CRLF] 1*WSP) /   ; Folding white space
>                         obs-FWS
(In reply to comment #84)
> I think that RFC 2822 is a newer spec than RFC 2045. If so, the old MUAs
> cannot resolve the quoted string that has whitespaces?

RFC 2822 is an update of the original RFC 822; the folding of headers is covered in the older document as well.
Thank you for your comments.

So, we don't have any problems in old behavior excepted the encoding style. Therefore, we should go back the encoding style only in name param.

value of param folding table:
    name encoding    filename encoding     RFC 2047 encoded values are split?
0   RFC 2047         RFC 2047              N
1   RFC 2047         RFC 2047              Y
2   RFC 2231         RFC 2231              N/A
3   RFC 2047         RFC 2231              N
4   RFC 2047         RFC 2231              Y

'3' is default value.
Attachment #255101 - Attachment is obsolete: true
Attachment #255208 - Flags: superreview?(mscott)
Attachment #255208 - Flags: review?(mscott)
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Comment on attachment 255208 [details] [diff] [review]
Quirks patch rv3.0

mcow/masayuki, thanks for the due diligence on this bug.
Attachment #255208 - Flags: superreview?(mscott)
Attachment #255208 - Flags: superreview+
Attachment #255208 - Flags: review?(mscott)
Attachment #255208 - Flags: review+
Attachment #255208 - Flags: approval-thunderbird2+
One thing I just cannot understand: how do I send attachments named in Japanese, Chinese, Russian, Hebrew etc. with Thunderbird?

Thunderbird DOES NOT allow to attach files that contain a single Unicode character in their names.
checked-in to trunk and 1.8 branch.

-> FIXED

(In reply to comment #89)
> mcow/masayuki, thanks for the due diligence on this bug. 

And Kimura-san helped me, thanks!

(In reply to comment #90)
> One thing I just cannot understand: how do I send attachments named in
> Japanese, Chinese, Russian, Hebrew etc. with Thunderbird?
> 
> Thunderbird DOES NOT allow to attach files that contain a single Unicode
> character in their names.

The unicode file names can be used only on trunk. (I forget 1.8 branch...)
In 1.8.0 branch (Tb1.5), the file names depend on the system locale, so if the system locale is Japanese or something, we can use the Japanese or something file names.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8.1.2
Resolution: --- → FIXED
Ok, so what do I do if I must send a file that contains Japanese, Greek, and Russian characters in its name? Which locale should I use then?
---The unicode file names can be used only on trunk.---

You mean, in Tunderbird v2 beta? They can't. Thunderbird can attach the file "夢で織らせない.txt", but sending the message results in an error:

"Sending of message failed.
Unable to open a temporary file D:/Dokumentai/_______.txt. Check your temporary directory setting."
(In reply to comment #93)
> ---The unicode file names can be used only on trunk.---
> 
> You mean, in Tunderbird v2 beta? They can't.

I don't know about Tb v2 beta, but with 1.5.0.9 it's very much possible to send a file named "テストファイル.txt".

I'm using Tb 1.5.0.9 on Linux with the locale set to de_DE.UTF-8.

> Thunderbird can attach the file
> "夢で織らせない.txt", but sending the message results in an error:

I just attached a file named "夢で織らせない.txt" and was able to send it.

I suppose it's a problem peculiar to your OS. And it also has nothing at all to do with this bug...
---I'm using Tb 1.5.0.9 on Linux with the locale set to de_DE.UTF-8.---

I think all my problems would be completely solved if I changed my Windows XP (Windows NT, Windows 2000) locale to UTF-8, but Microsoft was not smart enough to include this option in its products.

---I suppose it's a problem peculiar to your OS. And it also has nothing at all to
do with this bug...---

Your supposition is correct. But 90% of people who own computers will not be able to repeat the steps indicated in this bug as they use Windows operating system that does not offer any UTF-8 support.
On Linux, if the locale is UTF-8, the unicode file names can be used on tb1.5 too. 

(In reply to comment #92)
> Ok, so what do I do if I must send a file that contains Japanese, Greek, and
> Russian characters in its name? Which locale should I use then?

You should not change the your system locale on Windows only for the testing. Because some applications will break your system. It's so risky...
---You should not change the your system locale on Windows only for the testing.---

For what kind of testing? I am a linguist, I need to send files with Devanagari, Japanese, Russian, Greek, Arabic characters and combining diacritics in their names. So how do I do that in Thunderbird under Windows XP?
(In reply to comment #97)
> ---You should not change the your system locale on Windows only for the
> testing.---
> 
> For what kind of testing? I am a linguist, I need to send files with
> Devanagari, Japanese, Russian, Greek, Arabic characters and combining
> diacritics in their names. So how do I do that in Thunderbird under Windows XP?

trunk nightly builds can send them.

Note that your comments are not scope of this bug. This bug only changes the name param behavior. Not for changing the file handling behavior.
---trunk nightly builds can send them.---

Did you read my previous posts?
(In reply to comment #99)
> ---trunk nightly builds can send them.---
> 
> Did you read my previous posts?

I tested to sending the non-system locale file name, but I cannot send it with trunk build on WinXP. But it's not a scope of this bug.
---But it's not a scope of this bug.---

Now it is the scope of this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=370748
Actually, there's an older bug for that:  Bug 332110.
(In reply to comment #93)
> ---The unicode file names can be used only on trunk.---
> You mean, in Tunderbird v2 beta?
No. Thunderbird 2 builds come from the 1.8 branch:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/
Trunk builds are those which will become Thunderbird 3:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/
---Trunk builds are those which will become Thunderbird 3:---

It doesn't matter. I tried them both. The problem is the same.
-> v. on trunk and 1.8 branch.

# I only tested the default setting, sorry.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.2 → verified1.8.1.2
Maybe my bug https://bugzilla.mozilla.org/show_bug.cgi?id=375990 using Seamonkey Messenger 1.1 email client is a duplicate of this bug. It contains attached test files with three Norwegian characters (from ISO 8859-1).

One possible difference: 
Seamonkey 1.1 on openSUSE 10.2 Linux looked to succeed to send the attached file names correctly to Windows/Outlook, while sending from Seamonkey mail client on Win2kTS to Windows/Outlook wasn't successful.

version 1.5.0.12 (20070509

hebrew language attachment file changed to att00XXX.xxx for outlook recipient 
aharon: update to thunderbird2.
Hello,

everyone please see

https://bugzilla.mozilla.org/show_bug.cgi?id=486682#c16

i believe your "fix" broke word encoding for large filenames because you remove the space between multiple encoded words - which is not right - see my last comment about this
Re-opening, because patch for this bug produced Bug 486682, due to "remove logic of [CRLF][SP]" in msg_make_filename_qtext which is currently called when aParmFolding=0/3.

To Nakano-san(Assigned To: person of this bug):

Default of aParmFolding=3 instead of aParmFolding=4 is intensional?
If yes, what is the reason?
Default change to current aParmFolding=4 instead of aParmFolding=3 is possible?
"Swap of meaning between aParmFolding=3 and aParmFolding=4" is possible?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to comment #116)
> Re-opening, because patch for this bug produced Bug 486682, due to "remove
> logic of [CRLF][SP]" in msg_make_filename_qtext which is currently called when
> aParmFolding=0/3.

Wada: that is not what we normally do, especially when a bug was fixed quite a few years ago. The correct procedure is to mark the new bug as blocking the bug that caused the regression and cc the appropriate people on the new bug.

We only reopen if a patch gets backed out or if it is clear that we didn't fix the bug in the first place (and typically the bug was fixed recently).
Status: REOPENED → RESOLVED
Closed: 17 years ago → 15 years ago
Depends on: 486682
Resolution: --- → FIXED
Try Long Path Tool that also useful in situations where you see these error messages. Such as Cannot read from source file or disk, there has been a sharing violation, cannot delete file or folder etc. Hope it will help you.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: