libsmbclient dfs changes

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

derrell at samba.org wrote:

> Hi Jerry, Kalim,
> 
> I spent some time looking through the changes to libsmbclient to add DFS
> support.  They generally look good, although I'm concerned about some possible
> performance issues.
> 
> 1. Currently, the code issues a cli_resolve_path() call for each
>    smbc_open_ctx(), smbc_read_ctx(), smbc_write_ctx() and smbc_close_ctx().
>    Unless the path can resolve to a different location each time, and we want
>    to follow the location even with an open connection that we're reading from
>    or writing to (unlikely), we should be able to resolve the path once at
>    smbc_open_ctx() time and use the resolved path for all further accesses to
>    the file with the now-open file descriptor.

True.

> 2. The code currently always does cli_resolve_path() *before* attempting the
>    native call.  DFS is likely the "fringe" case, not the common case, I
>    think.  Given that, is it possible to issue the native call first, assuming
>    that DFS is not in use, get back an error code that indicates that the path
>    must be resolved (if it is actually DFS), and *then* do the DFS-specific
>    stuff?

No.  If the share supports dfs,you pretty much have to check
for a referral first.  But the overhead only exists when talking to
DFS shares.

> 3. In the function cli_dfs_make_full_path(),
> 
>         if (*sharename == '\\') {
>                 server = sharename+2;
> 
>    Should that be sharename+1 ?

No.  It's trimming the double slash from a UNC path name.
I've been clidfs.c in smbclient for quite a while now so
the code has been tested pretty well.

> 
> 4. Less importantly...  In tracing through the code, I noticed that there are
>    numerous calls to cli_dfs_make_full_path(), first within cli_resolve_path()
>    a few times, and then in smbc_open_ctx().  Is it possible to build each
>    path only once?

Probably.  I'll have to look into it some more.

I don't think that any of this is reason to hold the 3.0.21pre1
release though.  Do you?




cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDU9oxIR7qMdg1EfYRAigHAKCClYAs2sWVhgUYPPvG+kf5+cVYxgCfZO7x
RBsprv7CFiJJqrCbRKjgfnY=
=ztLX
-----END PGP SIGNATURE-----