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

[Richard Hughes]

Thanks for the pointers. It looks like I'm going to have to do more
hunting, the ASCII to UNICODE problem looks most likely to me. I guess
if I study the CIFS spec I should have a better idea on what's going
wrong. I'll put some debugging in cifssmb.c and see what happens. 
Cheers,

  Richard Hughes


> > when a large number of files are present, it displays:
> > dir000.txt to dir122.txt and nothing more
> 
> There may still be a problem with resume keys.  The two problems that I had run into in the past 
> (and should be fixed) were:
> 
> 1) the second or subsequent FindNext hit end of search, but the kernel (filldir) returned an 
> error as cifs tried to add them to the directory listing during readdir, but the cifs client
> at one point did not reopen the search and got an invalid handle on trying to resume the search
> (using the old directory handle) from the last entry that the kernel took (the last successful
> filldir) on the previous readdir.
> 
> 2) the resume key was stored in ASCII but in some cases it was not converted back into Unicode
> and the findNext returned an error trying to resume from an illegal file name.
> 
> I still do not like the search logic (cifs_readdir) code - it is just about my least favority part
> of the code that I wrote - the NFS approach (grabbing a cache of NFS private pages to keep 
> the search results in until the last readdir is issued and the search is closed may be a better
> approach - but the memory utilization worries me)