[linux-cifs-client] Directory Listings Truncated

[Steven French]

> Looking at the Ethernet packets I see that I'm getting a
> STATUS_OBJECT_NAME_INVALID error on the FIND_NEXT2 command.
> I also see the the flag is set for strings are Unicode
> and that the filename being sent telling the XP machine
> where to continue from is not Unicode which obviously
> is the immediate cause of the error.

That problem should be fixed in current cvs version of 2.4 cifs vfs (it did
not seem to show up in 2.6 but a similar fix was applied there just in
case).   It was as you describe setting Unicode flag but not resuming with
Unicode string (filldir only takes ASCII strings - so the string was
converted - and when one of the many calls to the kernel routine filldir
returns errors as it does a lot on 2.4, the string needed to be converted
back to Unicode).

There is a remaining bug which needs to be fixed (I will try to do this
today) - e.g. say there were 105 files in a directory (file.001 to
file.105) and 60 entries were returned on findfirst, on the 50th call to
filldir the kernel returns an error - we then must reset the resume key
from file.060 to file.050 (actually I need to check the code to make sure
it is not file.049 that we want).  Then we issue the FindNext with the
updated resume key, Then we get the final 55 entries returned by the server
(in which the server returns the end of search flag).   The kernel again
fails filldir, say on file.101, we reset the resume key and send a new
FindNext with the updated resume key - the server thinks this second
FindNext has an invalid search handle because it has already told us that
the search is complete.    To get the last five entries requires closing
and reopening the search handle (FindClose followed by FindFirst, then
FindNext resuming at file.105).  A better solution may be for the
cifs_readdir code to hang on to a page containing the last search entries
rather than throwing them away and resuming at a new location.   I will
have to experiment with this - because the current approach is somewhat
inefficient on 2.4 - causing twice as much network traffic as necessary in
some cases - and defeating the whole point of using a relatively large
(16K) cifs buffer for holding the cifs search response data - since the 2.4
kernel apparently can not accept that much data fast enough.

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
-------------- next part --------------
HTML attachment scrubbed and removed