cli_list_new() bugs? (XP Home incompatibilities, anyway)

[Derrell.Lipman at UnwiredUniverse.com]

So I've been seeing smbc_opendir()/smbc_readdir() sporadically neglecting to
return files that actually exist.  It turns out that XP Home (at least; maybe
others) sometimes neglects to return all of the files in a
FINDFIRST2/FINDNEXT2 sequence of calls.  I found a fix (kludge?) but I'd sure
like to know whether this is just an XP Home limitation like the small number
of concurrent connections it allows, or if there's something more generically
wrong that would affect other windows versions.

cli_list_new() issues a "Find First", requesting up to 512 results.  In my
case, the returned packet contains 36 of the 102 total files in the folder.
The data for these 36 files require a couple of NBSS Continuation packets.

cli_list_new() then issues a Find Next", requesting an additional 512 results.
It (incorrectly?) sets the ResumeKey to 0.  From the (seriously lacking) CIFS
protocol documentation, I believe that ResumeKey should be set to the
LastFileOffset value from the previous result.  (This is not the cause of the
current problem, but could cause other problems later -- or changing it from
its current "0" could cause other problems later; I don't know.)

The returned result, this time, begins ONE FILE TOO LATE; i.e. it skips one
file from the folder -- *sometimes*.  This returned result, as with the first
one, contains a number of NBSS Continuation packets.

When the next "Find Next" is issued and the result returned, it, too, is
missing the very first file that should have been returned, IFF it was missing
the first time; i.e. if it works properly in the first Find Next result, it
will work properly for the remainder of the Find Next results in the set of
requests.

Using ethereal, I have determined that there are only minimal differences in
the FindFirst / FindNext requests in a working scenario and a non-working
scenario.  Firstly, the NextFileOffset is different by 4 bytes in the result.
(This is what led me to find that ResumeKey was always being set to 0 and I
thought that maybe providing the NextFileOffset back to ResumeKey would fix
things.  It did not.)  Secondly, the data at the end of the Continuation
packet differs.  By "at the end", I mean the data which follows the last
filename data, which I suspect is NBSS Continuation packet data but I don't
now how that's encoded.

In my sequence of 102 files, 2 were missing.  The SearchCount field in the
result is short by 2 in the very last FindNext result.

My "fix" for this was to change the maximum number of results requested, from
512 to 24.  Since XP Home was returning at most 36 when in fact the request
was originally for 512, it clearly isn't able to generate a large list.  I
suspect there may be some border condition where it loses track of where it
was.

I'd love to hear from the SMB protocol gurus on this.  I'd hate to have to
limit the returned results to 24, increasing the required number of FindNext
requests, but I'd certainly prefer that to data loss!

Thoughts?

Cheers,

Derrell