[PATCH/RFC]: More robust directory listing.

[Joakim Plate]

Hi, 

Just a small thought on how directory listings are handled in
interpret_long_filename when info level 1 and 2 are used. Why is clistr_pull
return value used to increment p? If for some reason that call fails due to
some unicode conversion issues (or something else), it will incremeant p
with an invalid value and break any following files.

Since the packet includes the length of the string, wouldn't that be safer
to use? I attached a patch that does so (it's untested since i don't even
know the exact meaning of the len field). The code mentions differences
between win2000 and 98, but not what the exact difference is. Doesn't the
len parameter include the terminating zeros in one of the cases?

On another note. In cli_list_new, the loop that parses out all filenames,
should probably not only rely on the number of files recived, it should
probably also make sure that p2 is never incremented outside the data_size.
It could segfault easily with an improperly formated response as it is now.
Best would probably be to add a parameter to interpret_long_filename wich
indicates the remaining size of the buffer.

/Joakim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clilist.patch
Type: application/octet-stream
Size: 632 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061023/238c6e42/clilist.obj