On Tue, Mar 22, 2005 at 05:52:17PM -0800, Jeremy Allison wrote:
> On Tue, Mar 22, 2005 at 08:43:22PM -0500, Derrell.Lipman@UnwiredUniverse.com wrote:
> > Ok, here's what I know so far...
> >
> > The over-the-wire stuff looks approximately correct. However, when
> > cli_list_new() calls fn(mnt,&finfo, Mask, state) near the bottom of the
> > function, it properly calls it with each of the files in the FINDFIRST
> > response (including all that are in continuation packets) but then appears to
> > call it with the file name from last entry in the FIRSTFIRST response for what
> > should be each of the files in the FINDNEXT responses.

>
> The part of the function that calls fn() looks like :
>
> for (p=dirlist,i=0;i > const char *mnt = cli_cm_get_mntpoint( cli );
>
> p += interpret_long_filename(cli,info_level,p,&finfo);
>
> fn( mnt,&finfo, Mask, state );
> }
>
>
> dirlist should be the raw memory buffer containing the level responses
> from the findfirst appended with all subsequent findnext's. total_received
> is the sum of all the ff_searchcount returned from the client. The
> interpret_long_filename returns the number of bytes consumed in this
> filename entry. So p should be walking through the dirlist buffer one
> entry at a time once all the ff/fn level info has been placed into it.
>
> I don't see a bug in this....


Can you do a debug level 10 and you should see this debug firing in
the client code:

DEBUG(3,("received %d entries (eos=%d)\n",
ff_searchcount,ff_eos));

if this is reproducible for you it should be easy to spot the problem.
It doesnt' happen for me.

Jeremy.