Bug 3269 - Files included in wildcard search which do not match the wildcard
Files included in wildcard search which do not match the wildcard
Status: RESOLVED LATER
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.20b
x86 Windows 2000
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-17 08:12 UTC by Michael Lueck
Modified: 2007-04-03 23:47 UTC (History)
1 user (show)

See Also:


Attachments
Sample log 10 for the same activity as the screen scrape (10.14 KB, application/x-zip-compressed)
2005-12-16 17:37 UTC, Michael Lueck
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Lueck 2005-11-17 08:12:29 UTC
Win2K Client, SP4, "all" latest hot fixes... who can keep up with them all!

Server is Debian Sarge 3.1 with latest updates, Simo's packages of Samba from samba.org - the ones compiled for Sarge.

Filesystem on the server is XFS.

Linux kernel installed is from package kernel-image-2.6.10-1-686_2.6.10-6_i386.deb which is not part of stable, but was suggested due to bugs in XFS in the 2.6.x kernel which shipped when Sarge went into the deep freeze.

Maybe enough background, la bug then... Pretty simple to see I think, screen scrape below.

Z:\Download\Topic\OS2>dir ec*
 Volume in drive Z is data
 Volume Serial Number is 1F68-027E

 Directory of Z:\Download\Topic\OS2

08/07/2005  03:10p      <DIR>          EABrowser
11/16/2005  09:03p      <DIR>          eCS
               0 File(s)              0 bytes
               2 Dir(s)   5,832,462,336 bytes free

I don't think EABrowser should have been included in the result set.
Comment 1 Jeremy Allison 2005-12-15 09:26:14 UTC
This doesn't happen on most filesystems. Have you tried this on another filesystem types ? Attach a debug level 10 log to this report please.
Jeremy.
Comment 2 Michael Lueck 2005-12-16 17:37:32 UTC
Created attachment 1619 [details]
Sample log 10 for the same activity as the screen scrape

Jeremy, this log entry which is for the "extra" dir that shows up sort of catches my eye.

  name_map: EABrowser -> 2D27546D -> ECJ0Z1~P (cache=0)

Seems the Samba name mangle which only kept the first letter made the next letter "C"... I wonder if that caused the ec* name match to ring true?

Not sure if it matters or not, I did dir for "ec*" but in the log it as uppercased the letters making it "EC*". Just thought I would point out that I was keeping it consistent with the screen scrape.

Yes, only XFS on our servers at this time.
Comment 3 Jeremy Allison 2006-01-29 21:09:50 UTC
Looks like you're getting hit by this section of code from smbd/trans2.c:

if(!got_match && check_mangled_names && !mangle_is_8_3(fname, False, SNUM(conn))) {

                /*
                 * It turns out that NT matches wildcards against
                 * both long *and* short names. This may explain some
                 * of the wildcard wierdness from old DOS clients
                 * that some people have been seeing.... JRA.
                 */

                 pstring newname;
                 pstrcpy( newname, fname);
                 mangle_map( newname, True, False, SNUM(conn));
                 if(!(got_match = *got_exact_match = exact_match(newname, mask, conn->case_sensitive)))
                        got_match = mask_match(newname, mask, conn->case_sensitive);
}

I'll think about the implications of changing this, but it's obviously there for a reason.... Let me consider this some more.

Jeremy.
Comment 4 Jeremy Allison 2006-01-30 14:20:13 UTC
On Mon, Jan 30, 2006 at 08:22:24AM -0500, Michael Lueck wrote:
> OK, one idea came to mind. Not going to take the time to cover all conditions I
> have indeed thought can/will come up, just want to share the general idea and
> see if you think it is worth looking into or not.
>
> Set a global smb.conf setting something about wildcard filename matching,
> options are both, longonly, shortonly, default is both.
>
> If a directory search comes in with a wild card, the setting is checked and the
> search is performed against such files as is specified. If someone wanted to
> dir for "my~QUZRF.DOC" then it would still show up as there is no wild card,
> thus the normal "both" search would be performed and find the short filename.
>
> In my case I would set the new option to longonly mode, as I could care less
> about short names, ESPECIALLY when doing "show me bla*" type listing searches.
>
> OK, I think that explains the idea well enough. Have to run for now.

The "mangled names" parameter does that. If you set it to no then smbd
won't check the short names. Unfortunately that might break compatibility
with some Windws apps. The other thing you can do is set the "mangle prefix"
parameter to more than 1, this would also reduce the probability of a
collision.

Jeremy.
Comment 5 Michael Lueck 2006-01-31 07:26:09 UTC
Yea, except this is a bit different... Seems to me the REAL thing that causes this bug is that a wild card search checks both the long and short name. I dare say if a wild card search is coming in.... oh, I "guess" someone could do a dir for 'm~fe*' where they want all the short filenames starting with those four letters... I just think that is a bit of a stretch.

I guess I would have to set up a Windows share here a bit and do some testing to see how that behaves... yuck! ;-)

But really, can you think of a way where it would definitely be a bad thing to allow for the filespec to be searched for a wild card, and if one was found then search long names only?
Comment 6 Jeremy Allison 2006-01-31 13:09:26 UTC
Yes I can think of a bad thing, it would cause Windows clients that depend on this behaviour to break :-).

Not searching the short name could be added as an option, but it *will* break some Windows apps.

Jeremy.
Comment 7 Michael Lueck 2006-01-31 13:40:56 UTC
What does Windows do if the filespec search is longer than 8.3 and includes a wildcard? Seems like searching shortnames in that case would be useless as it would be impossible to find a match.

filespec = 'ThisIsMy WayCool filespec*'

The twist I am trying to emphasize is that Samba would only skip searching short names IF a wildcard is in the filespec someplace. In such a mode, the risk becomes not getting a file returned vs getting ones that does not belong. If there is no wildcard in the filespec, I fully agree that the existing behavior should be kept. 
Comment 8 Jeremy Allison 2006-01-31 14:13:19 UTC
> What does Windows do if the filespec search is longer than 8.3 and includes a
> wildcard? Seems like searching shortnames in that case would be useless as it
> would be impossible to find a match.

Yep, that's a worthwhile change I think.

> The twist I am trying to emphasize is that Samba would only skip searching
> short names IF a wildcard is in the filespec someplace. In such a mode, the
> risk becomes not getting a file returned vs getting ones that does not belong.

This I'm not sure of. I need to create a Samba4 torture test to check if this is the case. We need to do what Windows does here. If Windows does this, then fine - so can we. If not, it needs to be an option at the very least, not default behaviour.

It's hard to check if this is the case as Windows uses a 5 + 3 short name mangle algorithm. They may also check for existing conflicts, not sure. I'll try and think of a way to test this against Windows.

Jeremy.

Comment 9 Gerald (Jerry) Carter 2007-04-03 23:47:55 UTC
closing