[jcifs] Re: jcifs.smb.Dfs bugs
Michael B Allen
miallen at ioplex.com
Fri Apr 25 17:28:20 GMT 2008
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.
Michael B Allen
PHP Active Directory SPNEGO SSO
More information about the jcifs