[jcifs] NullPointer Exceptions with OES2

[Michael B Allen]

Travis,

The potential for negatively impacting the list code trying to work
around this bug is greater than the benefit. You might seriously
consider trying to contact Novell about this.

Mike

On Mon, Oct 25, 2010 at 10:39 AM, Travis Ennis <travis.ennis at gmail.com> wrote:
> 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
>



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/