[jcifs] Problem listing files from IBM iSeries server

[Sai Pullabhotla]

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
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/
>