Directory listing in libsmbclient.so

[Steve Langasek]

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

> Also, jcifs uses the following syntax to specify a resource as a URL:

> smb://domain\user:password@host:port/share/dir/file

> 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.  If you support specifying a workgroup,
it needs to be done separately from the specification of the domain.
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.

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

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. Perhaps browse lists could be represented as

   smb://<user>:<password>@.browselist/<workgroup>

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, and which
uses something as the <server> portion of the URL which won't cause a
namespace clash with a valid server name (no matter how poorly chosen).
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.

Regards,
Steve Langasek
postmodern programmer