On Tue, Mar 22, 2005 at 09:51:57PM -0500, Derrell.Lipman@UnwiredUniverse.com wrote:
> Jeremy Allison writes:
> > On Tue, Mar 22, 2005 at 09:24:03PM -0500, Derrell.Lipman@UnwiredUniverse.com wrote:
> >> Quick update... The problem appears to be that interpret_long_filename()
> >> is returning 0 as obtained from SVAL(base, 0) for each of the additional
> >> names, so interpret_long_filename() is being recalled with the same pointer
> >> over and over.

> >
> > Ok - it looks like the length field isn't being set correctly.
> > Hmmmm. I'll look at a patch to get around that problem. Thanks
> > for tracking this down !

> Ok, great. It kind of makes sense that the next entry offset would be zero at
> the end of the FINDFIRST response.

Yep - I realised that 2 minutes after I sent that email (just after I sat
down to dinner :-).

> Maybe an appropriate fix is to patch the "next entry offset" when you append
> 'p' to 'dirlist'... sort of like adding a new element at the end of a linked
> list???

Yes, but we only do this at the end of a packet. In fact the 2 byte
overwrite I removed as it was triggering valgrind was a broken attempt
to do just that :-). I'm guessing someone fixed this before (and didn't
quite get it right :-).

Give me an hour or so and I'll have a patch for you...