[jcifs] Changes in jCIFS

Mon Aug 1 23:35:25 MDT 2011

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
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. 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?
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