Directory listing in libsmbclient.so
simo.sorce at polimi.it
Wed Dec 27 18:46:45 GMT 2000
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.
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:
as servers domain name is not really important (but will give a sense of
> > 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
> - 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:
> \----> Server
> \----> service
> \----> directory
> Not unreasonable. That would give us something like:
> where workgroup is either a workgroup or ntdomain, and calling up
> would call up the list of available workgroups/ntdomains, and
> 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!
More information about the samba-technical