Do the following:

- on a WinXP (or XP64) PC map a drive to a NW CIFS share
- open a cmd prompt at the PC
- CD to any path of your choosing on the mapped drive, which contains
files with a "." in their filename (like "*.xml", "*.exe", "*.nlm",
"*.dll" etc.)
- enter "dir *.xyz" , where xyz is the file extension which some files
in this directory have

Now you will notice that *no* file is shown in the listing despite of
the fact that several files exist, which fulfill the search criteria

If you access the same directory via a NCP mapping all is working as

Problem seems to be, that Netware CIFS is unaware of the Wildcard
translations, which occur according to section 3.3 of the CIFS
specifications as follows:


3.3 Wildcards

Some SMB requests allow wildcards to be given for the filename. The
wildcard allows a number of files to be operated on as a unit without
having to separately enumerate the files and individually operate on
each one from the client.

If the client is using 8.3 names, each part of the name ( base (8) or
extension (3) ) is treated separately. For long filenames the . in the
name is significant even though there is no longer a restriction on the
size of each of the components.

The ? character is a wild card for a single character. If a filename
part commences with one or more "?"s then exactly that number of
characters will be matched by the wildcards, e.g., "??x" equals "abx"
but not "abcx" or "ax". When a filename part has trailing "?"s then it
matches the specified number of characters or less, e.g., "x??" matches
"xab", "xa" and "x", but not "xabc". If only "?"s are present in the
filename part, then it is handled as for trailing "?"s

The * character matches an entire part of the name, as does an empty
specification for that part. A part consisting of * means that the rest
of the component should be filled with ? and the search should be
performed with this wildcard character. For example, "*.abc" or ".abc"
match any file with an extension of "abc". "*.*", "*" or "null" match
all files in a directory.

If the negotiated dialect is "NT LM 0.12" or later, and the client
requires MS-DOS wildcard matching semantics, UNICODE wildcards should
be translated according to the following rules:

Translate the ? literal to >

Translate the . literal to " if it is followed by a ? or a *

Translate the * literal to < if it is followed by a .

The translation can be performed in-place."

If you take a packet trace you see, that the Windows client translates
the search pattern "*.xyz" to "<.xyz" according to the above cited
paragraph, but the server responds with no files.

Windows explorer does not use such detailed search patterns, it just
searches all files and then matches them internally with the search
pattern as does Linux if you try the same on a CIFS mount with "ls

This is a big problem because applications using the .NET framework use
the same detailed search patterns, that the dir command uses and
therefore fail in simple file searches erroneously.

W. Prindl