SOC smbclient progress

[derrell at samba.org]

Kalim M <kmoghul at gmail.com> writes:

> 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.

Yeah, that's what I thought you wanted to do.  I had thought for a while about
doing something like passing additional info from the file_info back to the
user during smbc_readdir() by formatting the returned "file name" with
embedded null chars, something like this:

  filename.txt\0size=<size>\0otherparm=<value>\0...\0\0

or

  filename.txt\0size=<size>;otherparm=<value>;...\0

but that's just way too kludgy for my taste.


If smbc_stat() is unable to get information that firstfirst/findnext is able
to retrieve, then I wonder how much slower it would be to implement
smbc_stat() in terms of firstfirst?  We just need to be sure that all of the
existing info provided by qpathinfo is also available with whatever we replace
that by.  Also, depending on the windows version being talked to, the times
(mtime, etc.) are formatted differently and IIRC, can differ in whether they
are GMT or localtime.  We'd need to handle those differences in the return
value from findfirst as well (if they are, in fact different there too).

Derrell