[jcifs] Dfs: 2 problems and one proposal
grambo at aventail.com
Wed Mar 17 00:37:35 GMT 2004
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().
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.
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 using a HashMap instead, with the referral path as key and the referral as element, and the attached SmbTransport.java has versions of getDfsReferral() and lookupDfsReferral() that implement this change. This change avoids collecting duplicates and also fixes the second problem above, because lookups now don't require iterating through a list.
Secure access for the real world.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8583 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20040316/cd80a88c/SmbTransport.java.tar
More information about the jcifs