[jcifs] Re: jcifs.smb.Dfs bugs

[Ronny Schuetz]

Hi Mike,

>> The usage of the "referrals" cache seems to be wrong, as it seems to be
>> flushed at the wrong places and the cache flushes might clear too many 
>> entries.
>>
>>  From my point of view, entries in this cache should not be removed or 
>> at least not at the places where they are currently removed. In 
>> #resolve(), they are removed (if they are expired) immediately before 
>> they are used; in insert(), too many entries might be removed, as there 
>> is only one expiry time for the whole map.
>>
>> Actually I had some SmbAuthExceptions due to this issue that appeared in 
>> a renameTo() call immediately after this cache has been flushed. I 
>> changed the referrals object to a simple hashmap and removed the object 
>> recreation / flush code in order to resolve the issue.
>>
>> Probably #insert() might need to be called more often in order to 
>> refresh the referrals, but I don't know where to do that yet. Will 
>> investigate further.
> 
> You'll have to be more specific.
> 

Looks like my previous assumption was totally wrong, I apologize. I was 
misled by the null values returned by SmbFile#getDfsPath() just before 
renameTo() failed. Adding an exists() calls directly before renameTo() 
as discussed earlier in this list helped here for most of the cases.

Btw, run into a minor issue with the DFS failover as well: I'm using a 
standalone root for testing (as I cannot create a domain root) and setup 
a link that has a replica in the following way:

  Link L1 -> Replica 1 -> Share A -> \\myhost\shareA -> Directory A
             Replica 2 -> Share B -> \\myhost\shareB -> Directory A

I.e. it is not real replica, the shares are just pointing to the same 
directory. I don't know if that really simulates a domain root with 
automatic replication properly, but this way I can test what happens if 
I take one replica offline and remove the share behind it.

In my code usually resolve the directory I need to pull/push files 
to/from once and keep the resulting SmbFile object. The SmbFile objects 
for the files to process are then retrieved via SmbFile#list resp. the 
SmbFile#SmbFile(SmbFile, String) constructor.

This does not work when the replica goes offline and the share is 
removed. jCIFS resolves the DFS links properly again, but for whatever 
reason the SmbFile still tries to access the removed share.

However, if the SmbFile object is created using SmbFile#SmbFile(String, 
NtlmPasswordAuthentication) for each file access instead of keeping the 
SmbFile object jCIFS switches to the remaining replica properly, so I'll 
change my code appropriately here.

But it looks like jCIFS does not react, if a replica is just taken 
offline or removed from the DFS configuration as long as the share 
(previously) configured as link is still accessible. Dfs#resolve() 
returns the right share to use (i.e. the remaining one), but even new 
SmbFile objects created using the DFS root URL continue to access the 
share which has been taken offline / removed.

>> #getTrustedDomains() / Domain address resolution
>> ================================================
>>
>> The domain resolution
>>
>>   UniAddress addr = UniAddress.getByName(auth.domain);
>>
>> in this method was very slow for me. I turned out that it was unable to 
>> resolve my domain, so I changed this line to
>>
>>   UniAddress addr = UniAddress.getByName(auth.domain, true);
>>
>> which resolves the issue, as the domain can be resolved properly now.
> 
> Lookups are timing out. You probably need different name resolution
> properties.

It looks like. For whatever reason, the domain name can be resolved by
DNS only (which is the last one in the list, the other lookup methods
below are obviously timing out) although it is a NetBIOS name, if
UniAddress.getByName() is called with possibleNTDomainOrWorkgroup=false.
However, if this flag is set to true, the WINS lookup succeeds immediately.

So as it is clearly a domain lookup, why not set the
possibleNTDomainOrWorkgroup flag to true?

Best regards,
Ronny