[jcifs] Dfs: 2 problems and one proposal

[Michael B Allen]

Gary Rambo said:
> I've attached a gzipped amended 0.8.2 SmbTransport.java.
>
> One problem I've had is with dfs paths coming back with an extra '/' in
> the dfs share name, as in  "smb://localserver/dfsroot//share/path". This I
> can fix at line 622 (625 amended) by removing a leading '/' from dr.share,
> although the source of the extra '/' lies in some parsing code earlier in
> getDfsReferral().

Fixed.

> Another problem is that if I have a dfsroot directory with two dfslinks
> with the same base name, e.g. "JPDFS" and "JPDFS-KANA", JPDFS-KANA will be
> searched for as a resource on the JPDFS link. This results from the test
> at line 639 of lookupReferral(), which is satisfied when the length of
> dr.path (JPDFS in this case) is met, but the length of the unc (JPDFS-KANA
> in this case) is not. This would be easy enough to fix by testing for both
> lengths.

Actually the intention was that if the referral path is a prefix of the
target path that referral should be used. I think the correct fix is to
just make sure it matches a full path component. Adding an extra
conditional to make sure either the referral path length and unc length
are equal or that the unc path.charAt( len ) == '\\' in lookupReferral
will do that.

> A more general problem I've had is that the data structure in which
> referrals are stored, a LinkedList, quickly grows large with duplicate
> entries if many calls are made to send() or sendtransaction(). I propose

I'm not seing that. I suspect this was happening because of the change you
made to match full UNC paths. There should never be more elements in the
list than there are dfs links on the server. The linked list is less
overhead if you have only a handful of entries.

Good work in finding these. No doubt it saved me a lot of time.

Thanks,
Mike