Created attachment 11556 [details] Windows command output create a directory and insert file with name 31253.SLDDRW running dir 33503*.* returns this filename. I think this should not happen. Also Delphi FindNext and Win32 API FindNextFile returnin this filename. Further test has shown you can also search for 335* the result is 31253.SLDDRW. Furthermore create a file named 31253.SLDD and search for 33* returns 31253.SLDDRW and 31253.SLDD. I've tested on 3 machines, one Samba 4.2, one 4.0 and one with older 3.6.6, result is always the same.
What version of Windows, what protocol on the wire ?
Tested from Windows 7 and an old Server 2003 machine. What do you mean with protocol ? The drive is attached with net use. I do not understand what you mean with protocol.
With Windows 7 this should probably be protocol SMB2, not SMB1. With Windows 2003 this will be SMB1 I think.
Ah - ok. It's matching the alternate name (which is what I expected). For a file named 31253.SLDDRW the alternate 8.3 (old DOS name) using the mangle2 hash algorithm is 335039~P, which matches your 33503*.* wildcard. Unfortunately we have to match on the alternate name due to the fact Samba on a POSIX filesystem supports file names containing such characters as '\' and ':' which are not visible from Windows. So when we come across such a filename we must map into an 8.3 alternate name. Now all filenames are implicitly mapped (as we still support DOS clients that only use 8.3 names) so we still must perfortm this mapping. In the meantime there are a couple of things you can do. 1). Set the share level parameter "manged names = no". This will disable name mangling but by default you won't be able to access names containing non-viewable Windows charaters. 2). Set the [global] parameter "mangling method = hash" (the default is hash2). This changes the mangling method to one that won't create a matching name. 3). Change the [global] parameter mangle prefix to a value greater than one (2 should do it) which changes the amount of name mangled.