Bug 775 - Japanese share names wrong format
Summary: Japanese share names wrong format
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 3.0.0
Hardware: Other FreeBSD
: P3 critical
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-13 16:56 UTC by Jonny Larson
Modified: 2005-08-24 10:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonny Larson 2003-11-13 16:56:52 UTC
We're using the Samba client 3.0.0 API to get file server access.  We have some 
Japanese Win2k servers that we test with.  This server has some share names 
that are in Japanese.  When I call cli_RNetShareEnum against this server, the 
names passed to my enum function are in the Shift_JIS character set.  This is 
even though the CAP_UNICODE capabilities flag is set after cli_negprot is 
called.  This causes the pull_ascii funtion to mash the names when it converts 
from CH_DOS to CH_UNIX inside of convert_string.

For files with Japanese names, the Samba API properly passes the names in 
Unicode.

To summarize, there's actually two problems:
1. The Unicode flag is set even though the share names are in Shift_JIS.

2. The names get mashed under the convert_string function hierarchy using the 
internal character conversion routines (utf8_pull, etc.).

We do not have ICONV (or GICONV) support compiled in.

I searched bugzilla for anything relating to this but found nothing.
Comment 1 Jonny Larson 2003-11-20 11:33:37 UTC
I was able to get around this by using the RPS NetShareEnum call.  RPC uses 
Unicode.  I don't have authority to change the bug status.  Feel free to close 
it however you see fit.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2004-03-16 11:56:01 UTC
closing.  Lot of mb string work done since original 
3.0.0 release as well.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:16:09 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.