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 mangled. I put the result at http://www.monyo.com/technical/samba/jchartest/20030505/ please diff (or windiff) between LOCAL.TXT and samba-3.0alpha23-CP932-20030505.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 'internationalization' category?)
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. Thanks, Jeremy.
- 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.