<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Martin,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have recently run into the same problem.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I think the problem is that SmbFile.resolveDfs() uses the currently connected transport as the DFS resolver/domain server (tree.session.transport.tconHostName), but it is very possible that there is no currently connected transport.  In your case, that happens when the file server forces the TCP connection to close, and the transport tears itself down.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>And, although the resolveDfs() method calls connect0(), in fact this does nothing because doConnect() doesn't force creation of a new connection if we are talking about a DFS resolved path.  <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It seems to me that in that case, we have to start over again at the top of the referral tree, with the Domain.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So my solution has this:  change the code for SmbFile.resolveDfs() lines 671 (or so) so that it says:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>        connect0();<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>>        String hostName = tree.session.transport.tconHostName;<o:p></o:p></p><p class=MsoNormal>>        String domainDfsServerName = getServerWithDfs();<o:p></o:p></p><p class=MsoNormal>>        if (hostName == null)<o:p></o:p></p><p class=MsoNormal>>            hostName = domainDfsServerName;<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>        DfsReferral dr = dfs.resolve(<o:p></o:p></p><p class=MsoNormal>>                    hostName,<o:p></o:p></p><p class=MsoNormal>                    tree.share,<o:p></o:p></p><p class=MsoNormal>                    unc,<o:p></o:p></p><p class=MsoNormal>                    auth);<o:p></o:p></p><p class=MsoNormal>                                                                                <o:p></o:p></p><p class=MsoNormal>The code comes from the other use of tconHostName, in SmbFile.doConnect():<o:p></o:p></p><p class=MsoNormal>        String hostName = getServerWithDfs();<o:p></o:p></p><p class=MsoNormal>        tree.inDomainDfs = dfs.resolve(hostName, tree.share, null, auth) != null;<o:p></o:p></p><p class=MsoNormal>In this code, we are getting the DFS resolver (which might be the domain server) as the hostName, and asking it to resolve our share. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Basically what this new code is saying is that:<o:p></o:p></p><p class=MsoNormal>- in the case where the transport has closed (ie, because of a timeout or TCP close on the DFS server side) reconnect to the DFS domain server in order to resolve a share's DFS server.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I can imagine a case where this doesn't work--if we have multiple levels of DFS redirection, where the domain server cannot redirect the client to a deep subdirectory.  But, I don't even know if this is possible in DFS.  If it is, then at least this solution removes the top level case and identifies the problem, which would require walking down the DFS resolution path to resolve the actual file server.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Conrad Herrmann<o:p></o:p></p><p class=MsoNormal>Primdaesk, Inc.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Hi,<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> I encountered a NullpointerException similar to<o:p></o:p></p><p class=MsoNormal>> https://lists.samba.org/archive/jcifs/2012-January/009856.html - at<o:p></o:p></p><p class=MsoNormal>> least the stack traces are similar.<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> My Environment (Client side):<o:p></o:p></p><p class=MsoNormal>> - jcifs 1.3.18<o:p></o:p></p><p class=MsoNormal>> - IBM JDK 7<o:p></o:p></p><p class=MsoNormal>> - AIX 7.1<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> The NPE occured in a (in-house) plugin for the Jenkins build server. In<o:p></o:p></p><p class=MsoNormal>> this system, JCIFs is used to recursively copy files from a Windows<o:p></o:p></p><p class=MsoNormal>> share to an AIX machine.<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> Re-running a build shortly after it finished triggered the NPE.<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> After some debugging, it seems to me like the SmbFile’s underlying<o:p></o:p></p><p class=MsoNormal>> transport is closed (by timeout), and when SmbFile.resolveDfs is called,<o:p></o:p></p><p class=MsoNormal>> the transport is not reconnected (unlike, for example, later in<o:p></o:p></p><p class=MsoNormal>> SmbFile.resolve, or in SmbSession.getChallenge).<o:p></o:p></p><p class=MsoNormal>>  <o:p></o:p></p><p class=MsoNormal>> I was able to reproduce the NPE during debugging using the following<o:p></o:p></p><p class=MsoNormal>> steps:<o:p></o:p></p><p class=MsoNormal>> - Trigger a build (recursively copying from a CIFS DFS tree)<o:p></o:p></p><p class=MsoNormal>> - Wait until the transport objects disconnect by timeout (tracked by<o:p></o:p></p><p class=MsoNormal>> breakpoint)<o:p></o:p></p><p class=MsoNormal>> - Retrigger the build (recursively copying the same directory structure)<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> The Jenkins plugin usually runs the second JCIFS copy operation in the<o:p></o:p></p><p class=MsoNormal>> same thread than the first (though that's not guaranteed).<o:p></o:p></p><p class=MsoNormal>> Each run uses a new SmbFile object.<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> Am I missing something (like some close operation on SmbFile)?<o:p></o:p></p><p class=MsoNormal>> Is this a known error?<o:p></o:p></p><p class=MsoNormal>> Can I do something to fix it?<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> Best regards,<o:p></o:p></p><p class=MsoNormal>> <o:p></o:p></p><p class=MsoNormal>> Martin<o:p></o:p></p><p class=MsoNormal>><o:p> </o:p></p></div></body></html>