<html><body><p>Although the changelog does not appear at glance to have addressed a problem that could cause this error, I should note that we're using jcifs 1.3.15 in this particular case. We're in the process of deploying 1.3.18. <br><br><br><tt>Colin Dean/Pittsburgh/IBM wrote on 04/27/2015 15:09:10:<br><br>> From: Colin Dean/Pittsburgh/IBM</tt><br><tt>> To: jcifs@lists.samba.org</tt><br><tt>> Date: 04/27/2015 15:09</tt><br><tt>> Subject: Unexpected fragment length exception when retreiving ACLs/<br>> SIDs on a file that has explicit permission granted to a deleted user</tt><br><tt>> <br>> Hello,</tt><br><tt>> <br>> I’m encountering an unexpected exception while retrieving SIDs/ACLs <br>> for a file served by Windows Server 2012 Standard Edition. We’re <br>> running on Windows in this instance, if that matters.</tt><br><tt>> <br>> Caused by: java.io.IOException: Unexpected fragment length: 28757</tt><br><tt>> at jcifs.dcerpc.DcerpcPipeHandle.doReceiveFragment<br>> (DcerpcPipeHandle.java:96)</tt><br><tt>> at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:220) </tt><br><tt>> at jcifs.smb.SID.resolveSids(SID.java:94)</tt><br><tt>> at com.vivisimo.connector.smb.SMBConnector.resolveSids<br>> (SMBConnector.java:629) ... 10 more</tt><br><tt>> <br>> This is approximately where our code hands off to jcifs to resolve the SIDs:</tt><br><tt>> <br>> SID[] sidsToResolveArray = sidsToResolve.toArray(new SID[0]);</tt><br><tt>> try {</tt><br><tt>> LsaPolicyHandle policyHandle = null;</tt><br><tt>> try {</tt><br><tt>> <br>> policyHandle = handle.openPolicyHandle(file);</tt><br><tt>> SID.resolveSids(handle.getHandle(), <br>> policyHandle, sidsToResolveArray);</tt><br><tt>> <br>> } finally {</tt><br><tt>> if (policyHandle != null) {</tt><br><tt>> LOGGER.debug("Closing Policy handle for [" +<br>> file + "]");</tt><br><tt>> policyHandle.close();</tt><br><tt>> }</tt><br><tt>> policyHandle = null;</tt><br><tt>> }</tt><br><tt>> } catch (IOException e) {</tt><br><tt>> throw new ConnectorException(e);</tt><br><tt>> }</tt><br><tt>> <br>> It dies shortly after we call SID.resolveSids() there in the middle <br>> of the inner try.</tt><br><tt>> <br>> We have a few theories:</tt><br><tt>> <br>> 1. This filesystem has a lot of files with Japanese characters in <br>> the filename. We considered that perhaps jCIFS or our software using<br>> it lacks support for Japanese characters, but we set up a testing <br>> environment with a bunch of files with Japanese filenames and it <br>> works for us. We’re pretty certain that our configuration mirrors <br>> that of the erring environment, but there might be subtle <br>> differences were are not able to replicate (e.g. real data instead <br>> of made up test data).</tt><br><tt>> <br>> 2. All of the files that are failing (we’re crawling a filesystem) <br>> share one trait: they have what appears in the Windows properties a <br>> permitted user that shows as “unknown user”, which may be an <br>> artifact remaining after the user was removed but its explicit <br>> permissions remained. Processing on a directory that has no “unknown<br>> users” yields no failures.</tt><br><tt>> <br>> This leads me to believe that jCIFS is failing on unknown users. <br>> However, looking through the source, I don’t see an obvious way to <br>> detect this.</tt><br><tt>> <br>> The obvious workaround appears to be “clean your unknown users” but <br>> I think this could be detectable and loggable during our processing <br>> of the share.</tt><br><tt>> <br>> I’d appreciate input on this.</tt><br><tt>> <br>> Colin Dean<br>> Advisory Software Engineer & Tech Lead, Watson Explorer Connectivity<br>> email: colindean@us.ibm.com | tel: +1 (412) 315-2066<br>> Find me on: [image removed] [image removed] [image removed] </tt><br><tt>> <br>> [image removed] </tt><br><tt>> <br>> [image removed] [image removed] [image removed] </tt><br><tt>> <br>> [image removed] </tt><br><tt>> <br>> <br></tt><BR>
</body></html>