Wildcard handling

[Andrew Tridgell]

> With regards to the problem reported by Richard Bollinger
> 
>   ...With nt smb support = no, when a win98 client 
>    types 'dir *.*', only filenames with a '.' in them
>    are returned by Samba.

well, if we want to emulate NT then this is in fact the correct
behaviour. I just tried using smbfilter to connect win98 to NT4server
and did a "dir *.*" at a win98 dos prompt with smbfilter set to remove
the "CAP_NT_SMBS" bit from the servers capability field. The NT server
returned only files with a '.' in the name.

What this means is that the behaviour on NT is definately not
determined by the server looking at the client type.

The next question is what sort of server are we trying to emulate when
we have "nt smb support = no". To determine that I would first like to
know *why* people use the "nt smb support" option. Is there some other
critical behaviour in Samba which needs that setting set to no? Can we
fix that and remove the option completely?

Finally, are there any known wildcard behaviours in Samba that differ
from NT server when "nt smb support" is left at its default value
(ie. true). If there are (even for some obscure client) then we need
to fix them, but we need to know what they are first.

My current thought is that if it turns out we do really need the "nt
smb support" option for some important purpose that we will need to go
through the whole fnmatch() development process again for a Win9X
compatible fnmatch() function and we will have to make it policy that
we try to emulate the Win9X server behaviour when "nt smb support" is
false. That option would then select a range of different function
implementations to try to emulate win9x.

I don't rate this as a top priority though, unless someone can tell me
why "nt smb support = no" is critical.

Cheers, Tridge