[mach-o]Unable to create a non-ascii folder on the local/pop tree

VERIFIED FIXED

Status

defect
--
blocker
VERIFIED FIXED
17 years ago
11 years ago

People

(Reporter: marina, Assigned: nhottanscp)

Tracking

Trunk
PowerPC
macOS
Dependency tree / graph
Bug Flags:
blocking1.4a -

Firefox Tracking Flags

(Not tracked)

Details

observed with ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-10-03-07-trunk
MacOSX10.1 Ja locale
Steps to reproduce:
- launch Mozilla;
- under Local try to create a folder using JA IME;
- type a japanese name;
//note: you are not able to OK the dlgbox, only Cancel it (it doesn't happen in
today's trunk 2002-10-03-08 build)
after the folder creation is cancelled and you close/expand again the Local tree
you'll see the folder but all actions with it (like copy to this folder will
fail), looks like it is not actually created at the back-end
I confirmed this problem using Mozilla1.3-MachO release build(20030312) on
MacOSX10.2.4.  But, Mozilla1.3a-CFM works fine.  Two Japanese reporters said in
Mozilla-gumi BBS that they did not reproduce this problem on
Mozilla1.3a-CFM(MacOSX10.2.4).  And they confirmed this problem on Mozilla1.3-MachO.

This problem seems to be caused by the transition from Carbon-based builds to
Mach-O builds.  Japanese users can't use Japanese at creating mail folder.  We
are in difficulty.  This bug should be fixed as soon as possible.

OS: WindowsXP -> MacOSX
 
Flags: blocking1.4a+
Keywords: nsbeta1
OS: Windows XP → MacOS X
Hardware: PC → Macintosh
Flags: blocking1.4a+
Request blocking 1.4a
This is critical bug for Japanese Mac OS X users.

Related bug: bug 194618
Flags: blocking1.4a?
See also Bug 194616
still happens with the latest trunk build: 2003032408 on JA locale and english
locale for accented chars, IMAP account is not a problem. Changing summary,
raising severity.
Severity: normal → blocker
Summary: [mach-o]Unable to create a JA folder on the local tree in JA locale → [mach-o]Unable to create a non-ascii folder on the local/pop tree
cc to ccarlen

I think the mail code uses nsIFileSpec. 
Conrad, are there changes for mach-o build which may affect nsIFileSpec?
nsIFileSpec is depending on the default system charset (e.g. MacRoman for
English locale, Shift_JIS for Japanese locale).
Severity: blocker → normal
cc naving, cavin, sspitzer

Naving, do you know which function of mailnews code creates local folder?
Severity: normal → blocker
There is an error creating a summary file using fopen.
http://lxr.mozilla.org/seamonkey/source/db/mork/src/morkFile.cpp#828

fopen for mach-o build failed with a filename in system's charset. I tried a
filename in UTF-8 and it seems to be working.
So, either mork or callers need change to pass UTF-8 filename (or use something
else instead of fopen). I think mork is used for IMAP but its summary filename
is always in ASCII. Addressbook might also have the problem (marina, could you
try ab?).

Seth, does your group have an engineer who is familiar with this area? I am not
sure which part the code we should change.
LXR shows many other places use fopen (security, NSPR, etc.). 
It is mentioned in Cocoa's developer.
http://cocoadevcentral.com/pipermail/cocoa-pro/2003-January/000298.html
I will file a separate bug for fopen/PR_Open issue since the issue is generic
and affects more components.
filed bug 199384 for the UTF-8 filename issue
Depends on: 199384
*** Bug 194616 has been marked as a duplicate of this bug. ***
tested Naoki's private build: the Local/Pop folder creation problem is fixed, no
regressions were introduced. Thanks, Naoki.
checked in the patch of bug 199384 to the trunk

Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
on Mozilla 1.4a (2003040103) with MacOS X 10.2.4:

When folder name is short, it operates correctly.
However, if the name is long (I entered about 20 characters
with japanese kanji character), some characters of the rear of the
mbox filename are changed to the ASCII character.
And after restart Mozilla, the mail folder displayed in the name
of the mbx filename which changed.
Flags: blocking1.4a? → blocking1.4a-
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030406

Now it works for me: I can create a folder named "Valérie".

Regards,
The long name issue might be related to the 32 character limit because the mail
code still uses FSSpec.
verifying with 2003050103 build, i am able to create a non-ascii folder on Local
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.