[jcifs] Problem listing files from IBM iSeries server
Michael B Allen
ioplex at gmail.com
Tue Dec 21 22:31:28 MST 2010
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
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?
> 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
> 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.
>>> 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.
>> Michael B Allen
>> Java Active Directory Integration
Michael B Allen
Java Active Directory Integration
More information about the jCIFS