[linux-cifs-client] Re: Incorrect FIND_NEXT2 transmission causing

[Richard Hughes]

Fixed it! Now I can do ls on a large share and there is no truncation.
CIFS works perfectly now. Enclosed is the minimal diff file, but I'll
write correctly the UNICODE debugging fixes and then post another diff.

I'm not sure why lastFindData->FileName was used, i don't think it was
even initialised.... pfindDataUnix->FileName gives the right values.


 Sorted. Richard Hughes

[root at laptop cifs]# diff file.c~ file.c
1796c1796
<                                               lastFindData->FileName,
---
>                                               pfindDataUnix->FileName,
1799c1799
<                                               lastFindData->FileName,
---
>                                               pfindDataUnix->FileName,


On Mon, 2004-05-03 at 17:10, Steven French wrote:
> > is:
> >FILE_DIRECTORY_INFO->FileName
> >FILE_UNIX_INFO->FileName
> >
> >meant to be ASCII or UNICODE? 
> 
> They can be either. For Samba 3 or later, or Windows 2000 or later you
> will usually see the server negotiate Unicode with cifs vfs (since
> cifs vfs supports unicode). The particular smb/cifs network request
> specifies unicode (instead of the old default ASCII) by a flag in the
> protocol header (SMB_FLAGS2 I think). Unless you are going to Samba 2,
> I think it more likely that it is Unicode
> 
> 
> Steve French
> Senior Software Engineer
> Linux Technology Center - IBM Austin
> phone: 512-838-2294
> email: sfrench at-sign us dot ibm dot com