Server: RH9 running samba-3.0.9 that includes the new ms_fnmatch routine from CAN-2004-0930.patch, locale is set to LANG=en_US.UTF-8 smb.conf settings: unix charset = utf-8 dos charset = cp852 display charset = LOCALE Client: Win2000 (or Win98) with a Czech locale, accessing a samba share from the command prompt, there is a file named Zakázka.doc (á is character U+00e1 Latin Small Letter A With Acute) dir Zak*.doc -> OK (the file is listed) dir Zaká*.doc -> File Not Found dir Zak?zka.doc -> File Not Found dir Zak??zka.doc -> OK Client: smbclient 3.0.9 connecting localy, the same share and filename dir Zak*.doc -> OK dir Zaká*.doc -> OK dir Zak?zka.doc -> NT_STATUS_NO_SUCH_FILE dir Zak??zka.doc -> OK The old ms_fnmatch routine in 3.0.7 did work, at least for the '*' matches.
Without having a Czech locale Win2k box handy, this might be a little difficult to reproduce. Can you send in an ethereal capture file showing the findfirst/findnext packets that are returning the wrong result. That way I can make smbclient use the same wildcard request to reproduce and test this. Thanks, Jeremy.
Ok, I'm pretty confident I've found and fixed the bug. The problem was in the new ms_fnmatch function the (incorrect) function strcpy_wa() was used to widen the mb strings to smb_ucs2_t instead of the (correct) push_ucs2(). I can reproduce the smbclient problem and the patch (attached) fixes it. I think this should fix it for the Windows client too. Jeremy.
The patch removes strcpy_wa() from the source as it serves no purpose I can see, although I'm going to check with tridge to be sure... Jeremy.
Created attachment 816 [details] Patch - seems to fix smbclient
I think I've fixed this now - please re-open if not. Jeremy.
Yes, the attached patch fixed the problem, it now works correctly for me from both Windows and smbclient. Thanks.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.