Bug 11579 - find files in directory with regex fails
find files in directory with regex fails
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
All All
: P5 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2015-10-29 16:38 UTC by christoph
Modified: 2016-02-09 10:17 UTC (History)
1 user (show)

See Also:

Windows command output (11.77 KB, image/png)
2015-10-29 16:38 UTC, christoph
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description christoph 2015-10-29 16:38:52 UTC
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.
Comment 1 Jeremy Allison 2015-10-29 16:48:38 UTC
What version of Windows, what protocol on the wire ?
Comment 2 christoph 2015-10-29 17:28:32 UTC
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.
Comment 3 Jeremy Allison 2015-10-29 18:07:29 UTC
With Windows 7 this should probably be protocol SMB2, not SMB1. With Windows 2003 this will be SMB1 I think.
Comment 4 Jeremy Allison 2015-10-30 23:53:48 UTC
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.