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
Request blocking 1.4a This is critical bug for Japanese Mac OS X users. Related bug: bug 194618
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?
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
*** 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.
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
You need to log in before you can comment on or make changes to this bug.