Re: Seven jCIFS bug fixes from Google.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google.

David Kaelbling
Hi,

Were the bug fixes from Google mentioned in CIFS Digest, Vol 140, Issue 1 included in jcifs 1.3.18?  The patch URLs in the original posting are no longer valid, so I’m hoping for an easy answer before I go hunting :-)

  Thanks,
  David


BLACKDUCK

David Kaelbling
Sr. Software Engineer
Black Duck Software, Inc.
800 District Avenue
Burlington, MA 01803
O: +1.781.425.4409

Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google.

Brett Johnson
The Google changes were not included in v1.3.18,
although that release did include a less-robust fix
for one of the issues. Google moved their open source
repositories to GitHub a couple of years ago. Its
jCIFS modifications can be found at:

https://github.com/googlegsa/filesystem.v3/tree/master/projects/jcifs

It should be noted that Google plans no further
changes to jCIFS.


Brett M. Johnson


Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google.

Christopher R. Hertel
If there is someone out there who would like to spearhead a new development branch of jCIFS, I'd be happy to provide insight into the workings of SMB.  I'm particularly interested in seeing SMB2/3 support added to jCIFS.

Chris -)-----

Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google./Future Development

Moritz Bechler
Hi,
> If there is someone out there who would like to spearhead a new
> development branch of jCIFS, I'd be happy to provide insight into the
> workings of SMB.  I'm particularly interested in seeing SMB2/3 support
> added to jCIFS.

RIght now we have dozens of unrelated and potentially incompatible forks
and patchsets of jCIFS out there - that really is a waste of everybodies
time.

I think the first thing we need to do is to somehow reunite these
efforts. If we all continue like this I guess we soon will be in a
situation where it will just stop working with new servers (or ones
configured for security) for all of us.

I'm not sure where upstream is actually abandoned or not, any comments
from there?

A while back I started working on a fork
(<https://github.com/AgNO3/jcifs-ng/>) featuring some major
architectural changes, including:
- removal of global state (one can now run multiple isolated clients)
- more flexibility in configuration, no longer forced to use system
properties
- cleaner abstraction of auth mechanisms, NTLMSSP, Kerberos support
- merged various patches

This required a few API breaks.

So I guess this might be a good starting point for a new development
branch. I'd be happy to merge other improvements and fixes and am
ultimately looking forward to adding SMB2+ support, but I don't think
thats an effort that I can tackle completely on my own in the near future.


regards

Moritz










Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google./Future Development

Michael B Allen
On Wed, Jun 22, 2016 at 11:26 AM, Moritz Bechler <[hidden email]> wrote:

> Hi,
>> If there is someone out there who would like to spearhead a new
>> development branch of jCIFS, I'd be happy to provide insight into the
>> workings of SMB.  I'm particularly interested in seeing SMB2/3 support
>> added to jCIFS.
>
> RIght now we have dozens of unrelated and potentially incompatible forks
> and patchsets of jCIFS out there - that really is a waste of everybodies
> time.
>
> I think the first thing we need to do is to somehow reunite these
> efforts. If we all continue like this I guess we soon will be in a
> situation where it will just stop working with new servers (or ones
> configured for security) for all of us.
>
> I'm not sure where upstream is actually abandoned or not, any comments
> from there?
>
> A while back I started working on a fork
> (<https://github.com/AgNO3/jcifs-ng/>) featuring some major
> architectural changes, including:
> - removal of global state (one can now run multiple isolated clients)
> - more flexibility in configuration, no longer forced to use system
> properties
> - cleaner abstraction of auth mechanisms, NTLMSSP, Kerberos support
> - merged various patches
>
> This required a few API breaks.
>
> So I guess this might be a good starting point for a new development
> branch. I'd be happy to merge other improvements and fixes and am
> ultimately looking forward to adding SMB2+ support, but I don't think
> thats an effort that I can tackle completely on my own in the near future.
>
>
> regards
>
> Moritz

Hi Moritz,

That all sounds great but I would like to caution anyone forking JCIFS:

I can see there are literally 5 pages of projects on github called
"jcifs". Not "jcifs-foo" or whatever but just "jcifs". If you or
anyone else creates a fork of jcifs, please do NOT call it "jcifs". If
someone builds it and makes a jcifs-x.x.x.jar they will not be able to
identify the fork from the original!

Mike

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

Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google./Future Development

Christopher R. Hertel
Agreed.

On Wed, Jun 22, 2016 at 9:14 PM, Michael B Allen <[hidden email]> wrote:
On Wed, Jun 22, 2016 at 11:26 AM, Moritz Bechler <[hidden email]> wrote:
> Hi,
>> If there is someone out there who would like to spearhead a new
>> development branch of jCIFS, I'd be happy to provide insight into the
>> workings of SMB.  I'm particularly interested in seeing SMB2/3 support
>> added to jCIFS.
>
> RIght now we have dozens of unrelated and potentially incompatible forks
> and patchsets of jCIFS out there - that really is a waste of everybodies
> time.
>
> I think the first thing we need to do is to somehow reunite these
> efforts. If we all continue like this I guess we soon will be in a
> situation where it will just stop working with new servers (or ones
> configured for security) for all of us.
>
> I'm not sure where upstream is actually abandoned or not, any comments
> from there?
>
> A while back I started working on a fork
> (<https://github.com/AgNO3/jcifs-ng/>) featuring some major
> architectural changes, including:
> - removal of global state (one can now run multiple isolated clients)
> - more flexibility in configuration, no longer forced to use system
> properties
> - cleaner abstraction of auth mechanisms, NTLMSSP, Kerberos support
> - merged various patches
>
> This required a few API breaks.
>
> So I guess this might be a good starting point for a new development
> branch. I'd be happy to merge other improvements and fixes and am
> ultimately looking forward to adding SMB2+ support, but I don't think
> thats an effort that I can tackle completely on my own in the near future.
>
>
> regards
>
> Moritz

Hi Moritz,

That all sounds great but I would like to caution anyone forking JCIFS:

I can see there are literally 5 pages of projects on github called
"jcifs". Not "jcifs-foo" or whatever but just "jcifs". If you or
anyone else creates a fork of jcifs, please do NOT call it "jcifs". If
someone builds it and makes a jcifs-x.x.x.jar they will not be able to
identify the fork from the original!

Mike

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




--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   [hidden email]
OnLineBook -- http://ubiqx.org/cifs/    -)-----   [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google./Future Development

Moritz Bechler
In reply to this post by Michael B Allen
Hi,

>
> That all sounds great but I would like to caution anyone forking JCIFS:
>
> I can see there are literally 5 pages of projects on github called
> "jcifs". Not "jcifs-foo" or whatever but just "jcifs". If you or
> anyone else creates a fork of jcifs, please do NOT call it "jcifs". If
> someone builds it and makes a jcifs-x.x.x.jar they will not be able to
> identify the fork from the original!

Sure, totally agree, not changing the artifact name for mine was merely
an oversight on my side.

However the damage is already done with various other forks and as I
said the I'm not too happy with the current state either.

I guess these forks come for different reasons:
- no public project infrastructure that people are now used to
(repository, issue tracking, pull request, ...)
- lack of artifacts (easily) usable in typical build processes
- features (potentially also fixes) not integrated in mainline (or only
as a patch)
- general lack of visible activity


Do you have any plans for future development? Would you be interested in
being involved in an effort to address to above-mentioned issues and/or
future-proofing the library?


regards

Moritz


--
AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
Persönlich haftend:
Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch

Reply | Threaded
Open this post in threaded view
|

Re: Seven jCIFS bug fixes from Google./Future Development

Michael B Allen
On Thu, Jun 23, 2016 at 1:03 PM, Moritz Bechler <[hidden email]> wrote:

> Hi,
>
>>
>> That all sounds great but I would like to caution anyone forking JCIFS:
>>
>> I can see there are literally 5 pages of projects on github called
>> "jcifs". Not "jcifs-foo" or whatever but just "jcifs". If you or
>> anyone else creates a fork of jcifs, please do NOT call it "jcifs". If
>> someone builds it and makes a jcifs-x.x.x.jar they will not be able to
>> identify the fork from the original!
>
> Sure, totally agree, not changing the artifact name for mine was merely
> an oversight on my side.
>
> However the damage is already done with various other forks and as I
> said the I'm not too happy with the current state either.
>
> I guess these forks come for different reasons:
> - no public project infrastructure that people are now used to
> (repository, issue tracking, pull request, ...)
> - lack of artifacts (easily) usable in typical build processes
> - features (potentially also fixes) not integrated in mainline (or only
> as a patch)
> - general lack of visible activity
>
>
> Do you have any plans for future development? Would you be interested in
> being involved in an effort to address to above-mentioned issues and/or
> future-proofing the library?

Hi Moritz,

Can I make a recommendation?

Create a github project called jcifs-bugfix that is just the stock
jcifs with bug fixes. Do not change the behavior in any way. Do not
change the API. Do not add features. Maintain full 100% backward
compatibility. Just apply bugfixes. Make the README.md just state
clearly that it is the *stock* jcifs with minimal *bugfixes* applied
and that it is fully backward compatible with the original
corresponding version of jcifs.

If you do that and you resist the temptation to "make the code better"
and just do the minimum necessary to fix real problems and you
actually understand the protocol and the code enough so that your
fixes genuinely work (most patches submitted are not correct in some
way), then your project would have a chance of being successful.

And put the built jar in the top level directory where people can just
grab the jar and go. If someone has to git pull and build it, they
won't try it. Just make sure the jar is jcifs-bugfix-1.3.18.jar.
Please do not call it jcifs-1.3.18.jar.

But again, do not add or change anything. Just do "stock jcifs with
bug fixes". There are a lot of real business users who don't care
about development. SMB1 works just fine and it's not going away
anytime soon. They just want something that works so that they can get
on with their business and go home and play with their kids. If you
can be professional enough to provide a service like that, it will
reflect well on your project and people will use it.

This might all sound very boring but when everyone starts to use your
build it won't be boring because people will appreciate what you're
doing and we all just want to be loved right?

When you get some traction and people start following your project,
you can nudge them over to you're new code.

Mike

Disclaimer: I have not looked at your code and I don't know if you're
qualified to be doing any of this. I have to say that because I want
to make it clear to anyone who might read this that my statements are
not an endorsement of you're work. My recommendation is directed at
anyone who might be interested.