[jcifs] jcifs bug

[Christopher R.Hertel]

On Fri, Mar 22, 2002 at 08:43:55PM -0500, Michael B.Allen wrote:
:
> > You should be able to completely parse the URL string into component
> > pieces and then handle the server vs. workgroup question as part of the
> > semantics of the connection establishment.
> 
> In practice this doesn't work.

Then there is an error in my specification.  The syntactic parsing of the
URL string *must* come before the semantics.  This is the kind of problem
that the RFC2396 guys were worried about.

> You'll push lookup code into the code
> used to represent the resource and you will end up with serious state
> consistentcy issues or major clauses all over the place. In theory
> it's possible but it's just a theory and one that I believe may have
> been proven false at one point.

I need to see that again so I can fix this.

> If we were just representing one type
> of resource it might not be a big deal but the workgroup v.s. server
> complicates things enough that it is better to eliminate that variable
> up-front.

I would agree, but the scales are weighted quite heavily on either side.  
This needs a bit more discussion.

> 
> > 
> > In our case, the <authority> field will typically be in the form of a
> > "Server-based Naming Authority", which means:
> > 
> >   <authority> :== <userinfo>@<host>:<port>
> > 
> > If the <userinfo> portion is present, then the following semantic rule
> > applies (assuming I'm not talking through my shorts):  Since the browse
> > service does not require authentication, the specification of <userinfo>
> > indicates that the request is for an smb server, not a workgroup.
> 
> This isn't the problem. It's the -- is foo in smb://foo a workgroup or
> server? -- issue.

Putting aside the question of <userinfo>, consider:

  smb://<authority>

given that, couldn't you simply parse the field into:

  <userinfo>@<host>:<port>

..and then do an NBT name lookup on <host>#1D?  That is all you would
need to do to find out if the <host> field represents a workgroup.  If you
get no reply to the <host>#1D name query, then the workgroup does not
(practially speaking) exist on the local LAN.

In parallel, you would perform whatever operations are needed to determine
whether the <authority> string represents an SMB server.

I need to code this up myself some time to be sure it works as I think it
should, but it should...I think.

> > > You can see this URL is "overloaded". So a query (actually two concurrent
> > > queries) must go out on the wire. Otherwise there would be no reason to
> > > go out on the wire; name resolution could be handled lazily.
> > 
> > How do you mean lazily?  Just curious.
> 
> If you return an object for which it's underlying resources have not
> been resolved the resouce would need to be lazily resolved like lazy
> read/write of a file system.

Makes sense... but you are right that in the smb://foo case you must send
the queries right away in order to discover if foo is an smbserver,
workgroup, or both.

Chridz -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org