| The basic syntax of an absolute SMB URL looks something like this: smb://[[[authdomain;]user@]host[:port][/share[/path][/name]]][?context] The stuff in brackets is optional, of course, and there are a lot of brackets. That means that there's a lot of potential variety in the formation of SMB URLs. Note, too, that this is the format for the absolute form of the URL. An implementation should also support relative URLs. [1] [1] This discussion assumes a basic knowledge of the workings of URLs and URIs (though it does not assume that you know the difference between a URL and a URI... I can't figure it out myself ). For detailed information on URIs, URNs, and URLs see RFC 2396 and RFC 2732. One of the fiddly bits that had to be handled when designing the SMB URL was whether the scheme identifier should be "SMB" or "CIFS". There wasn't a lot of argument over this. People just started using whichever they liked , so both were declared acceptable. In other words, " smb:// " and " cifs:// " both mean the same thing (and implementations should support both). We'll use " smb " here because it is more common (and because that's the one the author likes). smb:// With no host specified, this form of the SMB URL indicates the local SMB filesharing network. In practical terms, it means the set of NBT Workgroups on the local subnet. The way to handle this is to send an NBT broadcast query for the \x01\x02__MSBROWSE__\x02 name, thus locating any Local Master Browsers on the subnet. Query one or more of the LMBs for the list of known Workgroups, and report the results. This form of the URL does not currently have a defined meaning in an Active Directory environment. The suggestion is that it might be used to find an Active Directory server, using the client's own fully qualified DNS domain name as a hint. If a server is found, then its W2K domain name would be returned. smb://netbios_name If the host is specified using a NetBIOS name, then it might be the name of a Workgroup, or it might be the name of an SMB fileserver. The only way to know which is to send a few queries. Three queries, in fact one for each of three different versions of the name: The <20> names , of course, are registered by SMB fileservers. The <1B> and <1D> names are registered by the Domain Master Browser and Local Master Browser, respectively. Finding an SMB server is basic stuff; the browsers are a little bit trickier. LMBs can only be discovered using a broadcast query, but there may not be an LMB for the desired Workgroup on the local LAN. If the Workgroup has a DMB, it can be found by sending a query to the NBNS ( assuming that the address of the NBNS is known). Not all Workgroups have a Domain Master Browser, however, so the <1B> query may also fail. Querying for both browser types simply increases the odds of finding something usable. If, after all that, the netbios_name resolves to a Workgroup name, then the LMB or DMB should be asked for its list of member servers. If the URL resolves to an SMB fileserver, then the fileserver should be queried for the list of shares offered by the server. There are rare cases in which the netbios_name may resolve to both a fileserver name and a Workgroup name. This is generally caused by a misconfigured NBT network. The recommended way to handle this situation is to issue a warning so that the user knows that there is a problem, but then go ahead and list both the servers in the Workgroup and the shares offered by the server. A tool with a graphical interface could, for example, provide different icons to distinguish the differnet object types as shown in Figure C.1. [2] [2] The network depicted in Figure C.1 is obviously poorly managed. Coffee. Pthah. Figure C.1. Overloading in action It is rare, but possible in a misconfigured NBT network, that a Workgroup and an SMB fileserver will share the same NetBIOS base name. The client application should probably make an effort to help the user sort things out.  smb://dns_name If the host is specified as a DNS name or an IP address, then it can't represent an NBT Workgroup because Workgroups can only be identified by their NetBIOS names. It might, however, be an Active Directory server (a W2K Domain name). Once again, the implementor is faced with having to go to the wire to discover the semantics of the URL. In this case, it may be necessary to send an LDAP query to the host in addition to attempting SMB connections. The host may be a W2K Domain Controller, an SMB server, or both. Isn't overloading fun? smb://host/share smb://host/share/path smb://host/share/name smb://host/share/path/name The share is the root of the shared directory tree, path is a subdirectory within the share, and name is a filename. That should all be fairly familiar stuff. | 