[jcifs] Problem listing files from IBM iSeries server

[Michael B Allen]

On Tue, Dec 21, 2010 at 9:02 AM, Sai Pullabhotla
<sai.pullabhotla at jmethods.com> wrote:
> Well, after doing more reading and debugging, below is what I've
> found. Please note that I'm referring to the CIFS document at
> http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf. I ran

This document is almost completely useless and should be ignored. The
latest thing to look at would be [MS-CIFS] from the WSPP documents
from Microsoft. It was recently worked on quite a bit but I have not
looked at it so I cannot comment to it.

The best way to implement this sort of thing is to just look very
carefully at what the oldest supported OS does and copy it *exactly*.
The "exactly" part is the trick and in this case clearly JCIFS does
not copy XP exactly or it would all just work. This is partly because
there are a wide range of possible inputs (and results that are fed
back into requests as inputs) and because the JCIFS code in question
predates XP.

But if XP sets and uses the RESUME_FROM_PREVIOUS_END flag in the way
that you seemed to indicate enabled JCIFS to work with both OS400 and
Windows, then that sounds pretty good to me. Does it?

Mike

> the listFiles test on two shares (a Windows 2003 share and a OS/400
> share). I have 4 files in each of these shares with file1.txt through
> file4.txt. Tests were run with jcifs.smb.client.listCount set to 200.
> The log level is set to 10.
>
> With Windows 2003, when we send the Trans2FindFirst2 request, the
> reply does indicate the correct value for the lastNameOffset and (I
> guess we compute the lastName based on the returned offset. It also
> says that end of search is reached.
>
> With OS/400 however, we get lastNameOffset as zero, and we compute the
> lastName to be "." the first time. This is what is the root cause,
> because the server already returned all 6 entries (including "." and
> ".." as the first two entries). The weird thing to note is that the
> enfOfSearch is set to false (perhaps a OS/400 bug?).
>
> Now, looking at the CIFS document above, the help text for
> lastNameOffset says -
>
> "USHORT LastNameOffset; Offset into Data[] holding the file name of
> the last entry, if server needs it to resume
> search; else 0"
>
> So, I guess an SMB client should ignore a zero value for this field,
> and solely depend on the searchHandle along with the other supported
> flags?
>
> On Mon, Dec 20, 2010 at 2:29 PM, Michael B Allen <ioplex at gmail.com> wrote:
>> On Fri, Dec 17, 2010 at 2:19 PM, Sai Pullabhotla
>> <sai.pullabhotla at jmethods.com> wrote:
>>> I apologize if this message does not get associated with the correct
>>> thread, but I just subscribed to the list and did not know how to
>>> reply to an existing thread. Anyhow, this is regarding the issue with
>>> duplicate file names being returned by the SmbFile.listFiles() method.
>>> The original thread's subject is  "Problem listing files from IBM
>>> iSeries server"
>>>
>>> I briefly looked at the JCIFS code, and looked at the CIFS document,
>>> and was able to fix the issue by doing the following:
>>>
>>> The TRANS2_FIND_NEXT2 request is sent with all flags turned off. The
>>> crucial flag appears to be the RESUME_FROM_PREVIOUS_END flag. Setting
>>> this flag ensures that the next page (if any) starts at where it was
>>> left off.
>>
>> Hi Sai,
>>
>> Unfortunately the various CIFS documents are known to not reflect
>> reality and so in general they are ignored. The standard practice is
>> to simply mimic exactly the observed behavior of a slightly old
>> Windows client (Windows XP would be good at this point).
>>
>> However, your observation is very interesting. If the flags you
>> describe are set different between JCIFS and XP and changing them to
>> match resolves the issue that would be a clearly good fix. I would not
>> be shocked if it broke some other client like Netapp or EMC but I
>> think the flags should first match what XP is doing.
>>
>> Mike
>>
>>>
>>> I did some basic tests and everything seems to be working. Not sure if
>>> there was a reason for not setting this flag, but I want some one who
>>> is more involved with the API to verify this.
>>>
>>> I think we can also eliminate the SmbComFindClose2 request if we set
>>> the FLAGS_CLOSE_IF_END_REACHED when sending the
>>> TRANS2_FIND_FIRST2/NEXT2 requests. But this is not needed to fix the
>>> issue in question.
>>>
>>> I verified that this change still works good with different sizes set
>>> on jcifs.smb.client.listCount config option.
>>>
>>> Looking forward to get some feedback on this change.
>>>
>>> Thanks.
>>>
>>
>>
>>
>> --
>> Michael B Allen
>> Java Active Directory Integration
>> http://www.ioplex.com/
>>
>



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