[jcifs] Changes in jCIFS

Tue Aug 2 11:55:03 MDT 2011

On Tue, Aug 2, 2011 at 1:35 AM, Marco Eckert <marco.eckert at hob.de> wrote:
> On 08/01/11 19:25, Michael B Allen wrote:
>>
>> On Mon, Aug 1, 2011 at 2:35 AM, Eckert, Marco<marco.eckert at hob.de>  wrote:
>>>
>>> Hi Mike,
>>>
>>> The changes can be found in the diff file I attached.
>>> I used the jCIFS sources from version 1.3.16 (2011-06-24).
>>> The changes are only within the class:
>>> jcifs.smb.Trans2FindFirst2Response
>>>
>>> I exchanged the if-statement for the last-file checking in
>>> jcifs.smb.Trans2FindFirst2Response.readDataWireFormat(byte[], int, int)
>>> with something lighter.
>>>
>>> I tested everything in my environment and with all the features I am
>>> using and it works quite well. However, I could not figure out why the
>>> if-statement was that complex in the first place. So maybe my sollution
>>> brings other problems?
>>
>> Hi Marco,
>>
>> That if-statement checks to see if the "last name offset" supplied by
>> the server for the current chunk of names falls anywhere within the
>> valid range for a name in the list. The TRANS2_FIND_FIRST2/NEXT2
>> operation has several variations that can be used and unfortunately
>> the behavior of servers can differ even for one particular variation.
>> So that if-statement tries to generalize enough to cover different
>> cases.
>>
>> Unfortunately the CIFS list operation has always been a bit of a
>> nuisance. I believe IBM iSeries servers emits an incorrect list
>> response which JCIFS cannot handle. However, even though these servers
>> are sending bad data, the fact remains that they work with Windows
>> clients. So in theory it should be possible to make JCIFS work at
>> least equally well. This is the sort of thing that would have been
>> good to re-write at one of those interoperability labs. Unfortunately
>> I don't think they have great participation at this events anymore and
>> they're always California which is a bit far for me to go on my own
>> dime.
>>
>> Mike
>>
>
> Hi Mike,
>
> so it may happen, that my changes work in specific scenarios, but may
> fail again, as soon as I use the function with some other servers? I

Correct.

> will probably do some more testing on these changes as soon as I find
> some time. Then I can let you know how it turned out.
>
> As far as I noticed, the file list that OpenSolaris and FreeBSD returns
> is correct - but undergoes some segmentation.

TCP fragmentation should not have any effect.

> However, the typical file
> lists sent from a windows machine are packed into one single package. I
> can search for some wireshark traces I did and attach them if you like.
>
> Moreover, the regular behavior for OpenSolaris and FreeBSD is, that the
> files get sorted alphabetically descending, so the last file is at the
> bottom. Are there some cases in which the last file is at the top?

Again, there is no spec so there is nothing that says that the "last
file index" has to be at the end of the message. But I don't recall
ever seeing an message that did not place the last file at the end of
the message.

If I recall correctly, the problem has always been that the "last file
index" could point to different places within the segment of the
message representing the last filename depending on which server you
were talking to. So the code for handling this has always been a
little screwy. But that code was written over 10 years ago. It could
be that servers are a bit more consistent now and those extra screwy
clauses are not necessary.

But fragmentation and how things are sorted almost certainly has
nothing to do with anything.

Mike

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

> Because then, my code would fail and show the previously known behavior.
>
> Marco
>
>>> -----Original Message-----
>>> From: Michael B Allen [mailto:ioplex at gmail.com]
>>> Sent: Samstag, 30. Juli 2011 19:04
>>> To: Eckert, Marco
>>> Cc: jcifs at samba.org
>>> Subject: Re: [jcifs] Changes in jCIFS
>>>
>>> On Fri, Jul 29, 2011 at 3:37 AM, Marco Eckert<marco.eckert at hob.de>
>>>  wrote:
>>>>
>>>> Dear Mr. Allen,
>>>>
>>>> I work as a software developer for HOB Inc. in Germany
>>>> (www.hobsoft.com).
>>>>
>>>> We did 2 changes to the jcifs source:
>>>>
>>>> 1. We added a handler for setting a domain controller name/address, if
>>>> the domain controller isn't reachable from the domain's name. This
>>>> change is most likely of no interest for you, it's merely for a better
>>>> integration into our existing project.
>>>>
>>>> 2. We found that, on some samba implementations (e.g. Solaris), the
>>>> file-list isn't assembled correctly. So that, if a certain file/folder
>>>> limit is reached, the files will occur multiple times.
>>>> We found a solution for this, that works in our testing environment.
>>>>
>>>> Because the jcifs project is licensed under the LGPL v2.1, we wanted to
>>>> offer the changes back to you. Please tell us in which format you prefer
>>>> to get the changes.
>>>
>>> Hi Marco,
>>>
>>> Thanks for the feedback. I would be interested in knowing what change
>>> you made to correctly decode the errant file-list. If the change is
>>> not complex I would be happy with a simple explanation of the change
>>> or a code fragment or a fragment of diff output, etc.
>>>
>>> Otherwise, as per the LGPL, if you distribute a modified package, you
>>> need to make the source to that package available to the recipient by
>>> either including it with your product or through a link to your
>>> website. See the LGPL for details.
>>>
>>> Mike
>>>
>>> --
>>> Michael B Allen
>>> Java Active Directory Integration
>>> http://www.ioplex.com/
>>>
>>> Follow HOB:
>>>
>>> - HOB: http://www.hob.de/redirect/hob.html
>>> - Xing: http://www.hob.de/redirect/xing.html
>>> - LinkedIn: http://www.hob.de/redirect/linkedin.html
>>> - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html
>>> - Facebook: http://www.hob.de/redirect/facebook.html
>>> - Twitter: http://www.hob.de/redirect/twitter.html
>>> - YouTube: http://www.hob.de/redirect/youtube.html
>>> - E-Mail: http://www.hob.de/redirect/mail.html
>>>
>>>
>>> HOB RD VPN - einfach, sicher und flexibel  auf alle
>>> Unternehmensanwendungen und -daten zugreifen
>>>
>>> Praesentation unter: http://www.hob.de/rdvpn2/
>>>
>>>
>>> HOB GmbH&  Co. KG
>>> Schwadermuehlstr. 3
>>> D-90556 Cadolzburg
>>>
>>> Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic
>>>
>>> AG Fuerth, HRA 5180
>>> Steuer-Nr. 218/163/00107
>>> USt-ID-Nr. DE 132747002
>>>
>>> Komplementaerin HOB electronic Beteiligungs GmbH
>>> AG Fuerth, HRB 3416
>>>
>>
>>
>
>
> Follow HOB:
>
> - HOB: http://www.hob.de/redirect/hob.html
> - Xing: http://www.hob.de/redirect/xing.html
> - LinkedIn: http://www.hob.de/redirect/linkedin.html
> - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html
> - Facebook: http://www.hob.de/redirect/facebook.html
> - Twitter: http://www.hob.de/redirect/twitter.html
> - YouTube: http://www.hob.de/redirect/youtube.html
> - E-Mail: http://www.hob.de/redirect/mail.html
>
>
> HOB RD VPN - einfach, sicher und flexibel  auf alle Unternehmensanwendungen
> und -daten zugreifen
>
> Praesentation unter: http://www.hob.de/rdvpn2/
>
>
> HOB GmbH & Co. KG
> Schwadermuehlstr. 3
> D-90556 Cadolzburg
>
> Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic
>
> AG Fuerth, HRA 5180
> Steuer-Nr. 218/163/00107
> USt-ID-Nr. DE 132747002
>
> Komplementaerin HOB electronic Beteiligungs GmbH
> AG Fuerth, HRB 3416
>