SOC smbclient progress

[Kalim M]

On 8/17/05, derrell at samba.org <derrell at samba.org> wrote:
> "Gerald (Jerry) Carter" <jerry at samba.org> writes:
> 
> > derrell at samba.org wrote:
> >
> >> If you can think of a POSIX-like function that cli_list()
> >> could be wrapped in (or a way to implement one of the
> >> existing smbc_ functions using cli_list() instead of
> >> what it's already using to provide additional capability),
> >> then that would probably be worthwhile to implement.  If
> >> cli_list() can not easily map to a POSIX-like function, however,
> >> I'd like to leave this proposed addition out of the samba3
> >> libsmbclient so that we don't end up adding
> >> unnecessary backward-compatibility requirements to the
> >> samba4 library.
> >
> > Derrell,
> >
> > I think we just need to flesh out the dir_list_fn() in
> > libsmbclient.c.  cli_list() is already called by smbc_opendir_ctx()
> 
> Yes, I assumed that opendir() didn't or couldn't provide what Kalim was
> looking for.  Maybe that was a bad assumption.
> 
> What additional features, beyond what opendir() currently does, are required?
> The question is whether they can be exposed in a reasonably clean way, without
> affecting backward compatibility.
> 
> Cheers,
> 
> Derrell
> 

Hmm...opendir does use cli_list() after all. The problem is that the
file_info struct isn't saved  by dir_list_fn() and I don't see a way
to get to it through something like smbc_readdir(). I tried working
around that limitation using smbc_stat() which, when you get down to
it, uses qpathinfo (or SMBgetatr) which apparently isn't doing the
same job as when cli_list() uses findfirst/findnext.

I guess if dir_list_fn() can do a little more and save file_info that
would be ok. Of course, then we'll need a clean way to access that
data. Though, I really just want to be able to do something like pass
a more interesting function to cli_list() in place of dir_list_fn().
Not sure if there's a POSIX-happy way to do it but it would be nice.

-Kalim