Directory listing in libsmbclient.so

[Christopher R. Hertel]

> On Wed, 27 Dec 2000, Michael B. Allen wrote:
> 
> > On Tue, Dec 26, 2000 at 10:46:12PM +1000, Richard Sharpe wrote:
> > > Does anyone have any comments on this ...
> 
> > At one time thought about this for jcifs, although we do not support it
> > yet, is if the path points to a file it is resolved. If the path is to
> > a directory(or share) do a TRANS2_FIND_FIRST2/NEXT2. If the path does
> > not include the share do a NetShareEnum. If only smb:// is specified
> > list names of servers from the master browser(or perhaps broadcast a
> > node status but that might be rather rude).

Mike:  What Richard was talking about was doing a list of available 
workgroups/NTDomains at this point.  A call to smb://workgroup/ would 
list the servers in that workgroup/NTDomains.

> > Also, jcifs uses the following syntax to specify a resource as a URL:
> 
> > smb://domain\user:password@host:port/share/dir/file

If possible, it would be nice to get rid of the backslash. ('\')  I would 
like to see a nominal standard come out of this discussion.

> > but someone suggested that a domain is different from a
> > workgroup? Programmatically maybe but in practice is it profitable to
> > differentiate the two?
> 
> Yes, it is important to differentiate.

At what level?

>  If you support specifying a workgroup,
> it needs to be done separately from the specification of the domain.

Why?

> Effectively, 'domain\user' is the username you're using for authentication.
> What if a user wishes to browse workgroup2, using his credentials from
> domain1?  This should be allowed, and with inter-domain trust relationships it
> may even be necessary.

An ntdomain is simply an extension of a workgroup.  The ntdomain provides 
the additional functionality of:
- Cross-subnet browsing (via the DMB, but this is not significant to this 
  discussion)
- A single sign-on.

This latter is the critical point, but it can be hidden from the user.  
The syntax of the URI does not need to be different and the user should 
*not* need to care if the name represents a workgroup or an ntdomain.

> I'm glad that support for browsing workgroups is being considered for
> libsmbclient.  I always thought it was a major shortcoming of smbsh that
> you could only browse one workgroup per smbsh instance.  However, I really
> don't think the workgroup should be part of the smb:// URI.  The problem is
> that workgroups don't add heirarchical information.

Right, they are not heirarchical, but then neither are NetBIOS names.  
Still, if there are multiple workgroups/ntdomains available on the local 
wire, then the user should be able to access then all.  To do so, you 
need to be able to specify the workgroup.  I see no reason to lock this 
down in a config file.

> True, they're a useful
> tool for finding servers on the network, but the standard syntax for a URI is
> protocol://[user[:password]@]host[.domain][:port]/[directory/[subdir/]][file];
> the workgroup name doesn't provide any information needed to locate a
> resource, and therefore doesn't fit in this scheme.  It certainly shouldn't
> displace the hostname.

No, it would replace the domain if this scheme were used.

The problem, though, is that Windows allows either DNS or NetBIOS names to
be used to specify a service providing host.  libsmbclient should follow
suit (much to my chagrin).  In this case, the domain in the format above
would be the DNS domain.  Thus, we don't really have a place for the 
workgroup/ntdomain field given the above syntax.

> I do still think it's important to provide access to browse lists, I just
> don't think supporting this feature should introduce complexity into the URI
> used for file access.

A browse list can be thought of as a directory.  It's not much 
different.  The hierarchy would be:

workgroup/ntdomain
     \----> Server
              \----> service
                        \----> directory

Not unreasonable.  That would give us something like:

  smb://workgroup/[user[:password]@]host[.domain][:port]/[directory/[subdir/]][file]

where workgroup is either a workgroup or ntdomain, and calling up

  smb://

would call up the list of available workgroups/ntdomains, and

  smb://workgroup/

would provide the browse list of a specific workgroup/domain, etc.

> or something similar?  Basically, using a scheme that makes it clear we're
> looking at a browselist rather than at a share list on a server,

I see no advantage in this.  It just makes it more complex for the user.

> Or maybe it would be better to use something like
> 
>    nbns://<user>:<password>@<workgroup>/
> 
> since we're effectively looking at two different resource types here anyway?
> There's no reason why the above URI couldn't be used to provide a list of
> links to smb://<user>:<password>@<server>/ resources.

I have never seen a dns:// URI, and I don't think one is needed.  Nor do 
I think we need to have an nbns:// URI.  This gets handled behind the scenes.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz