<div dir="ltr">One of the patches from google submitted to the list last year:<div><br></div><div><a href="http://article.gmane.org/gmane.network.samba.java/9410">http://article.gmane.org/gmane.network.samba.java/9410</a><br></div><div><br></div><div>has an attempted fix of this.</div><div><br></div><div><a href="https://code.google.com/p/google-enterprise-connector-file-system/source/detail?r=563">https://code.google.com/p/google-enterprise-connector-file-system/source/detail?r=563</a><br></div><div><br></div><div>It seems to work for me - in any case it shouldn't ever throw that NPE out of resolveDfs.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div style="font-size:15px;padding-left:5px"><strong><font color="#000000">Shon Vella</font></strong><br></div><div style="font-size:15px;color:rgb(229,37,38);padding-left:5px"><b>Identity Automation</b></div><div style="font-size:15px;padding-left:5px"><font color="#000000">Product Engineer</font></div><div style="font-size:15px;padding-left:5px">281-220-0021 x2030 <span style="color:rgb(229,37,38)">office</span></div><div style="font-size:15px;padding-left:5px"><a href="tel:281-817-5579" value="+12818175579" style="color:rgb(17,85,204)" target="_blank">281-817-5579</a> <span style="color:rgb(229,37,38)">fax</span></div><div style="font-size:15px;padding-left:5px"><a href="http://www.identityautomation.com/" style="color:rgb(17,85,204)" target="_blank">www.identityautomation.com</a></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jun 15, 2015 at 5:45 AM, Martin Kutter <span dir="ltr"><<a href="mailto:martin.kutter@fen-net.de" target="_blank">martin.kutter@fen-net.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for your reply.<br>
I've tested 1.3.18b - it does not fix this specific error.<br>
<br>
Regarding the fix suggested by Conrad: In the meantime, I've also<br>
implemented a fix for the issue - I changed SmbFile.resolveDfs()<br>
(lines 671 and following) to<br>
<br>
DfsReferral dr = null;<br>
// disconnect is synchronized to transport, too.<br>
// make sure our transport doesn't get disconnected while<br>
// we're inside the synchronized block<br>
synchronized (tree.session.transport) {<br>
if (tree.session.transport.tconHostName == null) {<br>
// disconnect properly if connection is lost<br>
tree.treeDisconnect(false);<br>
}<br>
tree.session.transport.connect();<br>
dr = dfs.resolve(tree.session.transport.tconHostName,<br>
tree.share,<br>
unc,<br>
auth);<br>
}<br>
if (dr != null) {<br>
<br>
<br>
As my knowledge of CIFS is quite limited, I have no idea whether this<br>
is right (or has bad side effects).<br>
<br>
The idea behind is similar (but not equal) to Conrad's fix: In case the<br>
transport has disconnected, disconnect properly and reconnect.<br>
<br>
Best regards,<br>
<br>
Martin<br>
<br>
On Sun, 14 Jun 2015 11:37:48 -0400, Michael B Allen <<a href="mailto:ioplex@gmail.com">ioplex@gmail.com</a>><br>
wrote:<br>
<div class="HOEnZb"><div class="h5">> I have added this post to the list of people who have reported it to<br>
> the TODO list so that it can be considered when I get around to<br>
> looking at this.<br>
><br>
> Note that the 1.3.18b mentioned in the link cited is here:<br>
><br>
> <a href="http://jcifs.samba.org/old/jcifs-1.3.18b.jar" rel="noreferrer" target="_blank">http://jcifs.samba.org/old/jcifs-1.3.18b.jar</a><br>
><br>
> Although I cannot recall what it actually does anymore it might be<br>
> worth a try. We never received feedback about it.<br>
><br>
> Mike<br>
><br>
> On Sun, Jun 14, 2015 at 5:00 AM, Conrad Herrmann <<a href="mailto:conrad@primadesk.com">conrad@primadesk.com</a>><br>
> wrote:<br>
>> Martin,<br>
>><br>
>><br>
>><br>
>> I have recently run into the same problem.<br>
>><br>
>><br>
>><br>
>> I think the problem is that SmbFile.resolveDfs() uses the currently<br>
>> connected transport as the DFS resolver/domain server<br>
>> (tree.session.transport.tconHostName), but it is very possible that<br>
>> there is<br>
>> no currently connected transport. In your case, that happens when the<br>
>> file<br>
>> server forces the TCP connection to close, and the transport tears<br>
itself<br>
>> down.<br>
>><br>
>><br>
>><br>
>> And, although the resolveDfs() method calls connect0(), in fact this<br>
does<br>
>> nothing because doConnect() doesn't force creation of a new connection<br>
>> if we<br>
>> are talking about a DFS resolved path.<br>
>><br>
>><br>
>><br>
>> It seems to me that in that case, we have to start over again at the<br>
top<br>
>> of<br>
>> the referral tree, with the Domain.<br>
>><br>
>><br>
>><br>
>> So my solution has this: change the code for SmbFile.resolveDfs()<br>
lines<br>
>> 671<br>
>> (or so) so that it says:<br>
>><br>
>><br>
>><br>
>> connect0();<br>
>><br>
>><br>
>><br>
>>> String hostName = tree.session.transport.tconHostName;<br>
>><br>
>>> String domainDfsServerName = getServerWithDfs();<br>
>><br>
>>> if (hostName == null)<br>
>><br>
>>> hostName = domainDfsServerName;<br>
>><br>
>><br>
>><br>
>> DfsReferral dr = dfs.resolve(<br>
>><br>
>>> hostName,<br>
>><br>
>> tree.share,<br>
>><br>
>> unc,<br>
>><br>
>> auth);<br>
>><br>
>><br>
>><br>
>> The code comes from the other use of tconHostName, in<br>
>> SmbFile.doConnect():<br>
>><br>
>> String hostName = getServerWithDfs();<br>
>><br>
>> tree.inDomainDfs = dfs.resolve(hostName, tree.share, null,<br>
auth)<br>
>> !=<br>
>> null;<br>
>><br>
>> In this code, we are getting the DFS resolver (which might be the<br>
domain<br>
>> server) as the hostName, and asking it to resolve our share.<br>
>><br>
>><br>
>><br>
>> Basically what this new code is saying is that:<br>
>><br>
>> - in the case where the transport has closed (ie, because of a timeout<br>
or<br>
>> TCP close on the DFS server side) reconnect to the DFS domain server in<br>
>> order to resolve a share's DFS server.<br>
>><br>
>><br>
>><br>
>> I can imagine a case where this doesn't work--if we have multiple<br>
levels<br>
>> of<br>
>> DFS redirection, where the domain server cannot redirect the client to<br>
a<br>
>> deep subdirectory. But, I don't even know if this is possible in DFS.<br>
>> If<br>
>> it is, then at least this solution removes the top level case and<br>
>> identifies<br>
>> the problem, which would require walking down the DFS resolution path<br>
to<br>
>> resolve the actual file server.<br>
>><br>
>><br>
>><br>
>> Conrad Herrmann<br>
>><br>
>> Primdaesk, Inc.<br>
>><br>
>><br>
>><br>
>>> Hi,<br>
>><br>
>>><br>
>><br>
>>> I encountered a NullpointerException similar to<br>
>><br>
>>> <a href="https://lists.samba.org/archive/jcifs/2012-January/009856.html" rel="noreferrer" target="_blank">https://lists.samba.org/archive/jcifs/2012-January/009856.html</a> - at<br>
>><br>
>>> least the stack traces are similar.<br>
>><br>
>>><br>
>><br>
>>> My Environment (Client side):<br>
>><br>
>>> - jcifs 1.3.18<br>
>><br>
>>> - IBM JDK 7<br>
>><br>
>>> - AIX 7.1<br>
>><br>
>>><br>
>><br>
>>> The NPE occured in a (in-house) plugin for the Jenkins build server.<br>
In<br>
>><br>
>>> this system, JCIFs is used to recursively copy files from a Windows<br>
>><br>
>>> share to an AIX machine.<br>
>><br>
>>><br>
>><br>
>>> Re-running a build shortly after it finished triggered the NPE.<br>
>><br>
>>><br>
>><br>
>>> After some debugging, it seems to me like the SmbFile’s underlying<br>
>><br>
>>> transport is closed (by timeout), and when SmbFile.resolveDfs is<br>
called,<br>
>><br>
>>> the transport is not reconnected (unlike, for example, later in<br>
>><br>
>>> SmbFile.resolve, or in SmbSession.getChallenge).<br>
>><br>
>>><br>
>><br>
>>> I was able to reproduce the NPE during debugging using the following<br>
>><br>
>>> steps:<br>
>><br>
>>> - Trigger a build (recursively copying from a CIFS DFS tree)<br>
>><br>
>>> - Wait until the transport objects disconnect by timeout (tracked by<br>
>><br>
>>> breakpoint)<br>
>><br>
>>> - Retrigger the build (recursively copying the same directory<br>
structure)<br>
>><br>
>>><br>
>><br>
>>> The Jenkins plugin usually runs the second JCIFS copy operation in the<br>
>><br>
>>> same thread than the first (though that's not guaranteed).<br>
>><br>
>>> Each run uses a new SmbFile object.<br>
>><br>
>>><br>
>><br>
>>> Am I missing something (like some close operation on SmbFile)?<br>
>><br>
>>> Is this a known error?<br>
>><br>
>>> Can I do something to fix it?<br>
>><br>
>>><br>
>><br>
>>> Best regards,<br>
>><br>
>>><br>
>><br>
>>> Martin<br>
>><br>
>>><br>
</div></div></blockquote></div><br></div>