Hello, This was orginally reported in http://bugs.launchpad.net/bugs/260396. If you have any questions please let me know. Regards chuck
What's the latest kernel on which you've tested and seen this behavior?
If the problem is seen in very recent kernels (2.6.30 or 2.6.31), then please outline some steps to reproduce the problem.
Updating component.
No response in several months. Closing bug.
The bug is doing well, as of Ubuntu 10.4, kernel 2.6.32-22-generic :-( so it would be nice if someone could REOPEN it. A few steps to reproduce the problem -- see bugs.launchpad.net WITHOUT mapchars (ok): # mount -t cifs //aserver/whatever whatever -o iocharset=utf8 # ls whatever sprzęt # ls whatever/sprzęt file1 file2 WITH mapchars (wrong): # mount -t cifs //aserver/whatever whatever -o iocharset=utf8,mapchars # ls whatever sprzęt # ls whatever/sprzęt sprzęt # ls -l whatever/sprzęt/sprzęt ls: cannot access whatever/sprzęt/sprzęt: No such file or directory It happens if you have both mapchars and utf8, and the directory name contains a non-ascii character, say [áàéęź].
Reopening bug since there is now a reproducer provided.
This bug affects me, too. Reproduced with a Mac OS X server, a Debian client, and pam_mount.
Reproduced on Fedora 16 (kernel 3.1rc8) with a DNS-323 in the role of server (2.6.12.6-arm1). mapchars allows me to create filenames with ? in them (which is a big deal for songs) but screws up directories with Japanese characters in their names as described here (ditto a big deal for songs...)
Very interesting. The same directory (called Öőú, for testing) works with either iocharset=latin2,mapchars or iocharset=utf8 but not with iocharset=utf8,mapchars
(In reply to comment #9) > Very interesting. The same directory (called Öőú, for testing) works with > either > > iocharset=latin2,mapchars sorry, iso8859-2, not latin2 > > or > > iocharset=utf8 > > but not with > > iocharset=utf8,mapchars
In fs/cifs/readdir.c, there's this fragment: if (unicode) { pqst->len = cifs_from_ucs2((char *) pqst->name, (__le16 *) filename, UNICODE_NAME_MAX, min(len, max_len), nlt, cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); pqst->len -= nls_nullsize(nlt); } else { pqst->name = filename; pqst->len = len; } I ain't no kernel programmer, but this seems to be suspicious. In one branch, we simply change the value of pqst->name, in the other, we copy over to it.... :) Baldvin (In reply to comment #9) > Very interesting. The same directory (called Öőú, for testing) works with > either > > iocharset=latin2,mapchars > > or > > iocharset=utf8 > > but not with > > iocharset=utf8,mapchars
(In reply to comment #11) > In fs/cifs/readdir.c, there's this fragment: > > if (unicode) { > pqst->len = cifs_from_ucs2((char *) pqst->name, > (__le16 *) filename, > UNICODE_NAME_MAX, > min(len, max_len), nlt, > cifs_sb->mnt_cifs_flags & > CIFS_MOUNT_MAP_SPECIAL_CHR); > pqst->len -= nls_nullsize(nlt); > } else { > pqst->name = filename; > pqst->len = len; > } > > I ain't no kernel programmer, but this seems to be suspicious. ... suspicious, but correct. It is initialized to a scratch buffer. Sorry.
Oct 9 21:48:52 medve kernel: [ 614.141444] /home/baldvin/samba/linux-2.6.32/fs/cifs/readdir.c: CIFS VFS: in cifs_readdir as Xid: 53 with uid: 0 Oct 9 21:48:52 medve kernel: [ 614.141447] /home/baldvin/samba/linux-2.6.32/fs/cifs/readdir.c: Full path: \cdk2\Öőú start at: 2 Oct 9 21:48:52 medve kernel: [ 614.141448] /home/baldvin/samba/linux-2.6.32/fs/cifs/cifssmb.c: In FindFirst for \cdk2\Öőú Oct 9 21:48:52 medve kernel: [ 614.141451] /home/baldvin/samba/linux-2.6.32/fs/cifs/transport.c: For smb_command 50 Oct 9 21:48:52 medve kernel: [ 614.141452] /home/baldvin/samba/linux-2.6.32/fs/cifs/transport.c: Sending smb: total_len 112 Oct 9 21:48:52 medve kernel: [ 614.141453] | 0x00 0x00 0x00 0x6c 0xff 0x53 0x4d 0x42 | _ _ _ l <FF> S M B Oct 9 21:48:52 medve kernel: [ 614.141458] | 0x32 0x00 0x00 0x00 0x00 0x00 0x01 0xc0 | 2 _ _ _ _ _ _ <C0> Oct 9 21:48:52 medve kernel: [ 614.141461] | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 | _ _ _ _ _ _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141465] | 0x00 0x00 0x00 0x00 0x00 0x08 0x7c 0x08 | _ _ _ _ _ _ | _ Oct 9 21:48:52 medve kernel: [ 614.141469] | 0x00 0x08 0x20 0x00 0x0f 0x2a 0x00 0x00 | _ _ _ _ * _ _ Oct 9 21:48:52 medve kernel: [ 614.141473] | 0x00 0x0a 0x00 0x00 0x10 0x00 0x00 0x00 | _ _ _ _ _ _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141477] | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x2a | _ _ _ _ _ _ _ * Oct 9 21:48:52 medve kernel: [ 614.141481] | 0x00 0x42 0x00 0x00 0x00 0x00 0x00 0x01 | _ B _ _ _ _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141485] | 0x00 0x01 0x00 0x2b 0x00 0x00 0x17 0x00 | _ _ _ + _ _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141488] | 0x96 0x00 0x06 0x00 0x05 0x01 0x00 0x00 | _ _ _ _ _ _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141492] | 0x00 0x00 0x5c 0x00 0x63 0x00 0x64 0x00 | _ _ \ _ c _ d _ Oct 9 21:48:52 medve kernel: [ 614.141496] | 0x6b 0x00 0x32 0x00 0x5c 0x00 0xd6 0x00 | k _ 2 _ \ _ <D6> _ Oct 9 21:48:52 medve kernel: [ 614.141500] | 0x51 0x01 0xfa 0x00 0x00 0x00 0x00 0x00 | Q _ <FA> _ _ _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141504] | 0x00 0x00 0x5c 0x00 0x2a 0x00 0x00 0x00 | _ _ \ _ * _ _ _ Oct 9 21:48:52 medve kernel: [ 614.141508] | _ _ \ _ * _ _ _ Why the extra 00's after Öőú and \* ? This can be a smoking gun, because the extra 00's can mean that we want to FindFirst for \cdk2\Öőú\*, but rather the receiving system stops at trailing 0 after ú?
Heh, return i is the incorrect piece, in cifsConvertToUCS.
I've got a fix --- tested it, works beautifully. Quite simple: --- orig/linux-2.6.32/fs/cifs/misc.c 2009-12-03 04:51:21.000000000 +0100 +++ linux-2.6.32/fs/cifs/misc.c 2011-10-09 22:25:10.767951322 +0200 @@ -713,7 +713,7 @@ } ctoUCS_out: - return i; + return j; } void Best, Baldvin
Nice work. That patch looks correct to me too. The only additional thing I'd probably do is revise the comments above cifsConvertToUCS() to mention what that function is supposed to return (the number of wide characters in the resulting string, minus any NULL termination). Would you care to post that patch to linux-cifs@vger.kernel.org? It should probably get cc'ed to stable as well.
the code changed quite a bit in the meantime. Jeff: is this bug fixed also these days?
Yes, it was fixed upstream in c73f693989d7a7d99ec66a7065295a0c93d0b127.