[jcifs] jcifs bug

[Michael B.Allen]

On Fri, 22 Mar 2002 17:58:57 -0600
Christopher R.Hertel <crh at ubiqx.mn.org> wrote:

> On Fri, Mar 22, 2002 at 06:46:14PM -0500, Michael B. Allen wrote:
> > 
> > There's a noteworthy problem here. The jCIFS SMB URL is based on an IETF
> > draft that requires the authority component to be resolved *during the
> > parse* in order to determine if it's a servername
> 
> Well, that's why it's a draft.  ;)
> 
> > like:
> > 
> >   smb://server
> > 
> > or a workgroup name:
> > 
> >   smb://mygroup
> 
> 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. 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. 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.

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

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

-- 
May The Source be with you.