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

[Richard Hughes]

A little help please....

is:
FILE_DIRECTORY_INFO->FileName
FILE_UNIX_INFO->FileName

meant to be ASCII or UNICODE? It looks like ASCII from looking
 at cifspdu.h (char FileName[1];), but there are both 
conventions in file.c - 

specifically ASCII:

[general block, i.e. neither ascii nor unicode]
	cFYI(1,("Last file: %s with name %d bytes long",
	pfindDataUnix->FileName,
	cifsFile->resume_name_length));

and UNICODE:

if (Unicode == TRUE)
	qstring.len = cifs_strfromUCS_le
		(pfindDataUnix->FileName,
		(wchar_t *)
		pfindDataUnix->FileName,
		MAX_PATHCONF,
		cifs_sb->local_nls);

These apply to lots of routines that handle length and printing. 
Printing the UNICODE string through cFYI only prints the first
byte and I need to know which it's meant to be stored as 
internally. Anyone?

 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)