Directory listing in

Steve Langasek vorlon at
Wed Dec 27 16:27:57 GMT 2000

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


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


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.

Steve Langasek
postmodern programmer

More information about the samba-technical mailing list