Bug 141 - Files created over CIFS with long Japanese names (Shift-JIS) are not created correctly
Summary: Files created over CIFS with long Japanese names (Shift-JIS) are not created ...
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Extended Characters (show other bugs)
Version: 3.0.0preX
Hardware: All Linux
: P2 major
Target Milestone: 3.0.0rc2
Assignee: Jeremy Allison
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-01 00:11 UTC by Oded Porat
Modified: 2005-11-14 09:26 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 Oded Porat 2003-06-01 00:11:45 UTC
When creating a file/folder with a long name in Japanese, the file/folder is 
wrongly created - it
is unreachable:
It cannot be deleted, accessed, renamed etc.
the folder name was created in the following way:
right click --> create new folder. press F2 [for renaming] - copy the phrase in 
Japanese [which
probably means: 'new folder'] and paste it 20 times.
the phrase 'new folder' in Japanese containts 7 char. - i have no idea how it 
is (or to how
many char.) translated via the Samba.
Inside the Ethereal capture we saw samba replying - "No such file" when asked 
for the files
content of the specific folder.

We got the following error message in samba log (log level 10)
[2003/05/28 15:58:09, 0] lib/util_str.c:safe_strcpy_fn(502)
  ERROR: string overflow by 1 (256 - 255) in safe_strcpy [/æ<96>°ã<81><97>ã<81>
<84>ã<83><95>ã<82>©ã<83>«ã<83><80>æ<96>°ã<81><97>ã<81><84>ã<83><95>ã<82>©ã<83>«ã
<83><80>æ<96>°ã<81><97>ã]

Tested with Samba 3 CVS version
Comment 1 Oded Porat 2003-06-02 01:57:26 UTC
It looks like the call to safe_strcpy that produces the error message in the 
log is from function resolve_wildcards (file: reply.c)
Line: 3110: pstrcpy_base(pname2, root2, name2);

Oded.
Comment 2 Alexander Bokovoy 2003-08-11 14:49:47 UTC
Could you please show your smb.conf settings in [global] section?
Did you use a CP932 patch for glibc 2.2.5 from Japanese community or has it been
produced with stock glibc?
Comment 3 Oded Porat 2003-08-12 01:18:44 UTC
We use unpatched glibc-2.2.2 (RH71).

The client was Windows 2000 Professional with Japanese support (UTF-8).

smb.conf
[global]
        blocking locks = no
        dns proxy = no
        failover port = 33601
        interfaces = 10.0.11.230/255.240.0.0
        keepalive = 120
        level2 oplocks = no
        lock directory = /mnt/fs0/config/samba/%$(SAMBA_SERVICE)
        locking = no
        machine password timeout = 999999999
        map to guest = bad user
        name resolve order = lmhosts wins bcast host
        netbios name = rainbow
        oplocks = no
        password server = kenguro
        private dir = /cluster/config/samba
        root preexec = [ -L /mnt/cifs/%I ] || ln -sf /mnt/cifs/$(( RANDOM % 
${NUM_INSTANCES} )) /mnt/cifs/%I
        security = domain
        server string = ExaStore
        smbpasswd file = /cluster/config/samba/smbpasswd
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        winbind enum groups = yes
        winbind enum users = yes
        winbind gid = 10000-20000
        winbind separator = +
        winbind uid = 10000-20000
        workgroup = exanet-qa
Comment 4 Gerald (Jerry) Carter (dead mail address) 2003-08-28 09:34:55 UTC
should be fixed in latest SAMBA_3_0 cvs tree 
(to be included in 3.0.0rc2).  Please retest
Comment 5 Gerald (Jerry) Carter (dead mail address) 2003-08-29 08:00:32 UTC
I'm marking this as fixed in hopes that all of the mutibyte
character set work that was done for RC2 does resolve the 
problem.  If not, please reopen the bug
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-02-07 07:57:04 UTC
originally reported against 3.0aph24.  Bugzilla spring cleaning.  
Removing old alpha versions.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:22:20 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:26:11 UTC
database cleanup