The Samba-Bugzilla – Bug 79
Japanese character support is broken
Last modified: 2005-08-24 10:18:16 UTC
From a mail from Monyo:
Anyway, I checked Samba 3.0alpha23 and found 2 problems.
- toupper'ed part of 2byte chars: for example
under "unix charset = CP932", a longname for a character which code
is 0x8161 returned via GetLongPathName() is changed to 0x8141.
- a character which contained a byte of 0x5c will be mangled: for
example, under "unix charset = CP932", a filenames for a character
which code is 0x817c (or 0x835c) is mangled, but these should not be
I put the result at
please diff (or windiff) between LOCAL.TXT
LOCAL.TXT is the result against to Windows XP machine.
And Japanese Windows NT(also in 2000/XP) has unique case insensitive
feature for some KANJI characters which mean roman numeric (for
example, a 2byte character for 'IV'(U+2163) and a 2byte character
'iv'(U+2173) should be a same character as 'A' and 'a'. Where to put
this routine in current Samba code?
(didn't know which category to put this bug in, maybe we should add an
Monyo, can you check this out with the latest SAMBA_3_0
CVS (as of 27th august 2003) ? I'm hoping everything except
the "special" character problem will be fixed.
- toupper'ed part of 2byte chars:
is already fixed at least Samba 3.0.0beta1. Samba 3.0.0rc1 is also OK.
- a character which contained a byte of 0x5c will be mangled:
is the same problem as I reported in BUG#186,
So I think this case can be closed.
monyo says ok.
originally reported against 3.0alpha23. Bugzilla spring cleaning.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.