Samba 3.0.20 - findfirst optimization

[Dina Fine]

Hi Jeremy

I configured case sensitive = yes, mangled names = yes. Find First fails
to get an existing mangled file:
S:\>dir shlomi\
 Volume in drive S is c$
 Volume Serial Number is 2629-002B

 Directory of S:\shlomi

10/26/2005  09:04 AM    <DIR>          .
10/26/2005  09:21 AM    <DIR>          ..
10/26/2005  09:03 AM                 5 test().txt
10/26/2005  09:04 AM                 5 TKEIRY~Z.TXT
10/26/2005  09:03 AM                 6 hello.txt
               3 File(s)             16 bytes
               2 Dir(s)  360,156,233,728 bytes free

S:\>type shlomi\TKEIRY~Z.TXT
The system cannot find the file specified.

And also a tcpdump shows: (If you don't see the below output, I will
send you the whole tcpdump file)
 <<PBrush>> 
 
Thanks
Dina
-----Original Message-----
From: Jeremy Allison [mailto:jra at samba.org] 
Sent: Monday, October 24, 2005 8:57 PM
To: Dina Fine
Cc: samba-technical at lists.samba.org
Subject: Re: Samba 3.0.20 - findfirst optimization

On Mon, Oct 24, 2005 at 10:33:21AM +0200, Dina Fine wrote:
> Hi
> 
> I have a question regarding the findfirst optimization  in 3.0.20 
> version.
> It seems that it doesn't work if case-sensitive and mangling are 
> configured to yes and the path doesn't contain wild chars
> 
> If a findfirst request is a mangled file name and the case sensitive 
> is configured to yes then the stat in dptr_ReadDirName (line 593, 
> dir.c) will fail, and since the case sensitive is yes the function 
> will return with NULL in line 616.
> The mangling is not considered here at all.
> 
> Am I wrong? Do I miss something?

Ok, I've looked more closely at this - so you're wondering about a
findfirst request ending up (after smbd/filename.c
processing) with a pathname like :

\path\to\dir\MAN~GED.NAM

where the last component is a mangled name ? I don't think this can
happen. The reason is that if the path 

\path\to\dir\MAN~GED.NAM

exits, then coming out of the unix_convert() function the entire
pathname will be unmangled. If the path doesn't exist, then yes the last
component of the path will be left mangled, but then the findfirst
should fail anyway (as the file doesn't exist).

If you have a test case that can show Samba failing under these
circumstances I'd be glad to re-examine this.

Jeremy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/bmp
Size: 36786 bytes
Desc: PBrush
Url : http://lists.samba.org/archive/samba-technical/attachments/20051026/2d162e7f/attachment.bin