Directory listing in libsmbclient.so

[Simo Sorce]

On Wed, 27 Dec 2000, Christopher R. Hertel wrote:

> > 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?
Because ntdomains may have trust relationship so that user joe of
ntdomain1 may be valid user of ntdomain2
so if you want to connect to a share on a server in ntdomain1 as user joe
of ntdomain2 you should use a command like:

smb://ntdomain2/joe@ntdomain1/server/share

or

smb://ntdomain2/joe@server/share

as servers domain name is not really important (but will give a sense of
hierarchy anyway)

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

-- 
Simo Sorce - Integrazione Sistemi Unix/Windows - Politecnico di Milano
E-mail: simo.sorce at polimi.it
Tel.int: 02 2399 2425 - Fax.int. 02 2399 2451
-----------------------------------------------------------------
Be happy, use Linux!