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.
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.
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.
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.
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.
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?
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.
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.
> 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.
closing