[jcifs] NullPointer Exceptions with OES2

[Travis Ennis]

Mike,

I was making this more difficult than necessary largely because I was
looking at the wrong aspect of the problem. It wasn't that the
LastNameOffset was pointing to the byte immediately after the last
entry. The fix mentioned below would deal with that, but it was hard
to detect when that should happen automatically, so the solution was
less than ideal. The problem to focus on was the initial error we
reported: the NullPointerException. Guarding against that
NullPointerException in the writeString method of the
ServerMessageBlock class was the real solution although it didn't
immediately work. When operating against OES2 shares, it would start
giving errors saying that the response size was bigger than
rcv_buf_size. This was easily fixed by changing the default value of
that property:

System.setProperty("jcifs.smb.client.rcv_buf_size", "120832");

That value given above is arbitrary. It just needs to be larger than
the response size. I've tested these changes against both OES2 and
Windows shares.

Please let me know how you would like me to submit these changes back
to you to include in the main development branch.

Thanks,
Travis


On Wed, Oct 20, 2010 at 3:56 PM, Travis Ennis <travis.ennis at gmail.com> wrote:
> Mike,
>
> Just to see if I could do anything with the fact that the
> LastNameOffset in the Trans2FindFirst2Response object points to the
> byte
> immediately *after* the last entry in the file list, I added the
> following to the Trans2FindFirst2Response class on line 158 in version
> 1.3.14:
>
> // >>OES2 Fix
> if(CIFS_IMPL.equals("OES2")) {
>    bufferIndex += 1;
> }
> else {
>    bufferIndex += 2;
> }
> // OES2 Fix<<
>
> This changes works in that it is now possible to list
> files/directories in shares that contain over 2000 files/directories.
> However, it causes problems if you have the jcifs.smb.client.listCount
> or jcifs.smb.client.listSize property set to anything but the default.
> I've yet to discover the pattern under which the failure occurs, but
> the exception that is thrown is always the IOException thrown in the
> doRecv method of the SmbTransport class. It seems the size is always
> bigger than the rcv_buf_size when the failure occurs.
>
> Any ideas?
>
> Thanks,
> Travis
>
>
>
> On Mon, Oct 18, 2010 at 11:53 AM, Travis Ennis <travis.ennis at gmail.com> wrote:
>> Hi Mike,
>>
>> I have begun working on the issue that is discussed below under the
>> original subject of "StackTrace from Novell Open Enterprise Server 2."
>> I was wondering if you might share any insight on what you think the
>> issue might be and what might be done to fix it. I'm trying to speed
>> things along and if you could help me get past the stage where I'm
>> just digging through the code trying to figure out what is happening.
>>
>> Thanks,
>> Travis
>>
>>>> Thu Jul 8 12:21:05 MDT 2010
>>
>> Hi Roger,
>>
>> The LastNameOffset in the Trans2FindFirst2Response in your packet
>> capture (which you stated is Novell OES 2) points to the byte
>> immediately *after* the last entry in the file list.
>>
>> Windows always points to the beginning of the last entry as would be
>> expected. Although historically this field has always been a little
>> troubled. Windows 98 used returns a value that falls between the
>> begging and end of the last entry (and last I checked JCIFS handles
>> this properly). But I've never seen LastNameOffset point beyond the
>> end of the last entry.
>>
>> I have added this issue to the TODO list. I'm not sure when I'll get
>> around to fixing it but at least we have a definitive diagnosis
>> (actually the correct place to file the bug report would be with
>> Novell).
>>
>> Mike
>>
>> On Tue, Jul 6, 2010 at 11:08 AM, Roger Thomas <rthomas at stone-ware.com> wrote:
>>> Did the packet captures show the problem?   Is there anything else I can get
>>> for you?
>>
>> --
>> Michael B Allen
>> Java Active Directory Integration
>> http://www.ioplex.com/
>>
>>
>> --
>> Travis Ennis
>>
>
>
>
> --
> Travis Ennis
>



-- 
Travis Ennis