[jcifs] jcifs bug

Michael B.Allen mballen at erols.com
Sun Mar 24 06:45:54 EST 2002


I don't really want to get into this now. I have to re-write the whole
SMB URL thing anyway so when I do that I'll consider the possibily of
not querying the network during the parse. If I design the code around
that criteria I might come up with an elegant solution.

to be continued...

Mike

On Sat, 23 Mar 2002 11:29:39 -0600
Christopher R.Hertel <crh at ubiqx.mn.org> wrote:

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


-- 
May The Source be with you.





More information about the jcifs mailing list