[jcifs] DFS-Links and jcifs.smb.client.soTimeout
Tapperson Kevin
Kevin.Tapperson at hcahealthcare.com
Thu May 19 19:51:08 GMT 2005
>> while testing some DFS-stuff with jCIFS 1.1.10 I noticed the following behavior:
>>
>> When I'm trying to access a DFS-Link with a newly generated NPA-Object, I get
>> the expected DfsReferral-Excpetion. Now, when I'm trying to access the same DFS-
>> Link a second time (with the old NPA-Object as well as with a new one) I get an
>> "Invalid access to memory location"-Exception. This behavior only occurs when
>> there are less than <jcifs.smb.client.soTimeout> milliseconds between the two
>> trys. After waiting <jcifs.smb.client.soTimeout> milliseconds I get the
>> DfsReferral-Exception again.
[snip...]
>
>Or it's possible that there is a bug in jCIFS but you would need to
>provide more information about the steps necessary to reproduce.
I just noticed a _possible_ bug in jcifs today that may be related here. In the constructor for SmbComSessionSetupAndX, a compare is done to see if the auth challenge matches the server encryption key:
if( auth.hashesExternal && auth.challenge != session.transport.server.encryptionKey )
The challenge/encryption key, however, is a byte[]. I assume that it is only required that the contents of the byte[] match and not that the two actually refer to the same object. It appears that it would make more sense here to use !Arrays.equals(auth.challenge, session.transport.server.encryptionKey) instead of the != operator.
Do the challenge and encryption key really need to refer to the same byte[] object, or is it sufficient that the contents of the byte[] match?
Kevin Tapperson
More information about the jcifs
mailing list