[jcifs] jcifs-1.2.12 and DFS
kwright at metacarta.com
Mon Jan 8 18:11:16 GMT 2007
Michael B Allen wrote:
> On Sun, 7 Jan 2007 20:42:42 -0600
> "James Maupin" <james.maupin at metacarta.com> wrote:
>>With jcifs1.2.13b2, getDfsPath() does not give the
>>StringIndexOutOfBoundsException, however, it includes an extra slash at the
> Just fixed those two bugs. Try jcifs-1.2.13b3 in the download area.
> Unfortunately we're now seeing how delicate the DFS code is; change one
> thing and something else breaks. This is because a DFS referral triggers
> the 'tree' and 'unc' members of an SmbFile to change but many methods
> look at and operate on them in different ways. Hopefully there won't be
> too much back-and-fourth required to stabilize the code.
> Incedentially, I've noticed your ListFiles examples take 6+
> seconds. That's a sure indication of name service timeouts (NetBIOS
> name service queries are tried twice three seconds apart). Either set
> jcifs.netbios.wins to your WINS server or set jcifs.resolveOrder=DNS
> and your examples will run fast.
Mike - just a quick question - if we do not have WINS configured (e.g.
set jcifs.netbios.wins), the resolution order as coded in
UniAddress.java appears to be: LMHOSTS,BCAST,DNS. Is the timeout you
think we are having due to BCAST being in the resolution sequence? If
not, I really don't see what could be happening.
The other disturbing thing that James noted is that this performance
issue ONLY seems to occur for DFS lookups. He says he is seeing good
performance without DFS. I find this unnerving since I would presume
that the lookup order is the same for DFS as for normal share activity.
I've asked him to get a capture at log level 10, in hopes that there is
some indication there of exact what is timing out.
More information about the jcifs