[jcifs] Re: jcifs.smb.Dfs bugs

[Michael B Allen]

On Thu, 24 Apr 2008 16:40:06 +0200
Ronny Schuetz <Usenet.r96 at gishpuppy.com> wrote:

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

Is that a bug I said I was going to fix. What's the approx. date and
Subject of the thread?

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

Right. Once the tree is set that's it. You'll have to catch the exception,
create a new SmbFile object and try again.

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

Or that will work too.

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

It should react - with an exception. Does it?

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

Ahh, yes it should probably be true. I'll change it.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/