smbc_opendir() returns -1 but sets errno to 0

[Derrell.Lipman at UnwiredUniverse.com]

"Christopher R. Hertel" <crh at ubiqx.mn.org> writes:

> So, the workgroup<1D> name should not be getting resolved via the DNS at
> all.  As a workgroup name, and there is no assumption that it will match
> the host name of any host on your network.  From the smb.conf(5) man page:
>
>     Note that this method is only used if the NetBIOS name type being
>     queried is the 0x20 (server)  name type, otherwise it is ignored.
>
> The same is true for the <1B> name (the Domain Master Browser name).  
> This should not be resolved via the DNS because, again, the NetBIOS name
> is not going to match the DNS hostname of the system that registered it.

Let me disambiguate the matter a bit.  The workgroup name isn't actually the
one being looked up; it's the name returned as the master browser for that
workgroup.  I retrieved the workgroup name by browsing for workgroups:
smbc_opendir("smb//") and then browsed for servers in the workgroup:
smbc_opendir("smb://WORKGROUP_NAME").  Since there's no WINS server here, I
believe it determined the list of workgroups (and the master browser for each)
via broadcast query.  When receiving the responses, it therefore had access to
the IP address from which the response originated.  Would it be an appropriate
modification to libsmbclient, to cache the IP address from these responses, in
order to behave in a more expected fashion?

> Another thing to note (yeah, I know I'm full of this stuff...):
> Many Windows systems register both the machine<00> unique name and the 
> workgroup<00> group name.  If the workgroup name matches a machine name 
> then there will be a name registration conflict.

Yup.  I think this is handled in libsmbclient by assuming the name represents
a server unless no server by that name exists, in which case it changes the
assumption to the name representing a workgroup.

>> 2. Given that smbc_opendir() is returning -1, should errno be set to
>> something other than 0 to help identify the problem -- even though the NT
>> errno from which errno is being derived was "success"?
>
> Dunno.  Would have to check the workings of that function.  If those 
> values indicate an empty list, then it's behaving correctly.

0 indicates success, -1 indicates error with errno set to indicate which error
occurred, a la many posix functions.  There is no time that I know of, in
posix functions, that -1 is returned but errno set to 0.  An empty list should
probably be returned as a successful return value of 0.  (OTOH, this is not
really a successful result with an empty set since the result came from the
wrong MB.)

Is it ever possible for a MB to advertise itself as the MB for a workgroup,
but then return an empty list of servers?  It was my understanding that the
negotiation for master browser required a server in that workgroup to
determine whether it should be the MB, so it should at a minimum, return
itself...  No?

Derrell