ping for release

[David Byron]

Sorry to nag, but is the repo in a good state to release? Still hoping for the large file stuff to get a little farther out in the
world.

Thanks much.

-DB

_______________________________________________
libssh2-devel http:/

[Daniel Stenberg]

Post by David Byron
Sorry to nag, but is the repo in a good state to release? Still hoping for
the large file stuff to get a little farther out in the world.

I'd say we're in a decent shape.

[Alexander Lamaison]

Post by Daniel Stenberg

Post by David Byron
Sorry to nag, but is the repo in a good state to release? Still hoping

for the large file stuff to get a little farther out in the world.

Post by Daniel Stenberg
I'd say we're in a decent shape.

We should consider reverting the recent SFTP changes because they are known
to cause data loss. After the release we can add them back and work on a
proper fix.

Alex

[Daniel Stenberg]

Post by Alexander Lamaison
We should consider reverting the recent SFTP changes because they are known
to cause data loss. After the release we can add them back and work on a
proper fix.

Do you know which commits that caused this? I've seen some reports about
problems but I've not seen it clarified that recent changes caused them or
which commits it might've been.

[Alexander Lamaison]

Based on the bug report [1] I'm assuming it's these changes [2].
They're the only ones recently that modified MAX_SFTP_READ_SIZE.

[1] https://github.com/libssh2/libssh2/issues/50
[2] https://github.com/libssh2/libssh2/commit/d754fee2f24565d8c89dc37a7f05ba1222a7bfc4

Alex

Post by Daniel Stenberg

Post by Alexander Lamaison
We should consider reverting the recent SFTP changes because they are
known to cause data loss. After the release we can add them back and work on
a proper fix.

Do you know which commits that caused this? I've seen some reports about
problems but I've not seen it clarified that recent changes caused them or
which commits it might've been.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

[Jakob Egger]

Has anybody been able to sort this out in the last two months?

Is there anything else blocking the release?

Jakob

Post by Alexander Lamaison
Based on the bug report [1] I'm assuming it's these changes [2].
They're the only ones recently that modified MAX_SFTP_READ_SIZE.
[1] https://github.com/libssh2/libssh2/issues/50
[2] https://github.com/libssh2/libssh2/commit/d754fee2f24565d8c89dc37a7f05ba1222a7bfc4
Alex

Post by Daniel Stenberg

Post by Alexander Lamaison
We should consider reverting the recent SFTP changes because they are
known to cause data loss. After the release we can add them back and work on
a proper fix.

Do you know which commits that caused this? I've seen some reports about
problems but I've not seen it clarified that recent changes caused them or
which commits it might've been.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

--
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

_______________________________________________
libssh2-devel http://c

[Daniel Stenberg]

Post by Jakob Egger
Has anybody been able to sort this out in the last two months?

I haven't seen any attempts nor reports on the list since Alexander pointed
out the likely offending commits. I take that as a pretty strong sign that
there isn't a very strong desire to get a version out.

Post by Jakob Egger
Is there anything else blocking the release?

There are a few very interesting-looking pull requests pending, but we don't
need to do them before a release.

[Alexander Lamaison]

Post by Daniel Stenberg

Post by Jakob Egger
Has anybody been able to sort this out in the last two months?

I haven't seen any attempts nor reports on the list since Alexander pointed
out the likely offending commits. I take that as a pretty strong sign that
there isn't a very strong desire to get a version out.

I'm keen to see a new release, but I've been waiting to test whether the
commits I highlighted really do cause a problem or not. My trusty old test
suite that used to prove these kinds of things, depends on infrastructure
that no longer exists. I've started updating it, but it won't be finished
this week.

What about preemptively reverting those commits, making a release, then
immediately re-applying the commits to master. It's seems a shame to delay
other useful improvements.

Alex

[Daniel Stenberg]

Post by Alexander Lamaison
What about preemptively reverting those commits, making a release, then
immediately re-applying the commits to master. It's seems a shame to delay
other useful improvements.

So you're that sure just reverting them will fix the SFTP problems as of late?
If so, then reverting them now seems fine.

I'm not convinced putting them back as-is makes much sense though if they're
introducing these problems. Faster performance isn't that fun when it comes at
the priace of broken functionality.

I was wishing that someone who experienced the SFTP problems would try to
revert those two commits and verify that the problems go away and tell us
about this fact on the list.

[Jakob Egger]

I've now looked at the bug report. I was able to reproduce some of the issues with example-sftp by varying size of the buffer passed to libssh2_sftp_read().

I have found three separate bugs, and I've submitted a pull request with fixes here:
https://github.com/libssh2/libssh2/pull/75

Since two of the bugs were introduced by that commit that supposedly improves performance, we might alternatively just revert that commit, and make two of my fixes unnecessary.

Can anybody review my changes?

What about preemptively reverting those commits, making a release, then immediately re-applying the commits to master. It's seems a shame to delay other useful improvements.

So you're that sure just reverting them will fix the SFTP problems as of late? If so, then reverting them now seems fine.
I'm not convinced putting them back as-is makes much sense though if they're introducing these problems. Faster performance isn't that fun when it comes at the priace of broken functionality.
I was wishing that someone who experienced the SFTP problems would try to revert those two commits and verify that the problems go away and tell us about this fact on the list.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

_______________________________________________
libssh2-devel http://cool.ha

[Jakob Egger]

Another ping for release!

Sune Bredahl confirmed on Github that with my latest commits he can no longer reproduce the issues in sftp_read():
https://github.com/libssh2/libssh2/pull/75 <https://github.com/libssh2/libssh2/pull/75>

Does anybody else have time to test this, or are we good to go?

Jakob

Post by Jakob Egger
I've now looked at the bug report. I was able to reproduce some of the issues with example-sftp by varying size of the buffer passed to libssh2_sftp_read().
https://github.com/libssh2/libssh2/pull/75
Since two of the bugs were introduced by that commit that supposedly improves performance, we might alternatively just revert that commit, and make two of my fixes unnecessary.
Can anybody review my changes?

What about preemptively reverting those commits, making a release, then immediately re-applying the commits to master. It's seems a shame to delay other useful improvements.

So you're that sure just reverting them will fix the SFTP problems as of late? If so, then reverting them now seems fine.
I'm not convinced putting them back as-is makes much sense though if they're introducing these problems. Faster performance isn't that fun when it comes at the priace of broken functionality.
I was wishing that someone who experienced the SFTP problems would try to revert those two commits and verify that the problems go away and tell us about this fact on the list.
--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

[Daniel Stenberg]

Post by Jakob Egger
Sune Bredahl confirmed on Github that with my latest commits he can no
https://github.com/libssh2/libssh2/pull/75
<https://github.com/libssh2/libssh2/pull/75>
Does anybody else have time to test this, or are we good to go?

I commented on some minor nits on the commits there, but once we can get that
PR merged and some time for people to get that tested in the master branch I
think we should be in a decent state for release...

[Alexander Lamaison]

Post by Daniel Stenberg

Post by Alexander Lamaison
What about preemptively reverting those commits, making a release, then
immediately re-applying the commits to master. It's seems a shame to delay
other useful improvements.

So you're that sure just reverting them will fix the SFTP problems as of
late? If so, then reverting them now seems fine.

Pretty sure because I don't see anything else that touches the SFTP
code since the last release.

Post by Daniel Stenberg
I'm not convinced putting them back as-is makes much sense though if they're
introducing these problems. Faster performance isn't that fun when it comes
at the priace of broken functionality.

Agreed, although now Jakob has put some great fixes in, maybe the
situation is resolved.

Alex

[Daniel Stenberg]

Post by Daniel Stenberg
I'm not convinced putting them back as-is makes much sense though if
they're introducing these problems. Faster performance isn't that fun when
it comes at the priace of broken functionality.

Agreed, although now Jakob has put some great fixes in, maybe the situation
is resolved.

Yes, the comments in pull #75 (https://github.com/libssh2/libssh2/pull/75)
sounds really promising.

I'm actually mostly awaiting for response to my comments there (and possibly
some updated commits) and then I'd be prepared to merge. *Then*, after letting
that merge cook in master for a short while I think we're truly closing in on
a release.

[Daniel Stenberg]

Post by David Byron
Sorry to nag, but is the repo in a good state to release? Still hoping for
the large file stuff to get a little farther out in the world.

I've merged the "fix SFTP" patches from the patient Jakob Egger into master
now. I _think_ we might be in a decent shape for release now.

If you disagree, please tell us why. Also, please get the latest from git and
have a go at it to help us polish out the last few quirks before we ship.

I have also been notified about a security problem that will get fixed and
announced with the pending release.

[Alexander Lamaison]

Post by Daniel Stenberg

Post by David Byron
Sorry to nag, but is the repo in a good state to release? Still hoping
for the large file stuff to get a little farther out in the world.

I've merged the "fix SFTP" patches from the patient Jakob Egger into master
now. I _think_ we might be in a decent shape for release now.
If you disagree, please tell us why. Also, please get the latest from git
and have a go at it to help us polish out the last few quirks before we
ship.

I've just tested the latest from master and, unfortunately, it doesn't
compile with Visual Studio 2005. The new SFTP fix introduced uint64_t
and uint32_t, which aren't in C90. Please hold off releasing for now.

Alex

[Alexander Lamaison]

Post by Alexander Lamaison

Post by Daniel Stenberg

Post by David Byron
Sorry to nag, but is the repo in a good state to release? Still hoping
for the large file stuff to get a little farther out in the world.

I've merged the "fix SFTP" patches from the patient Jakob Egger into master
now. I _think_ we might be in a decent shape for release now.
If you disagree, please tell us why. Also, please get the latest from git
and have a go at it to help us polish out the last few quirks before we
ship.

I've just tested the latest from master and, unfortunately, it doesn't
compile with Visual Studio 2005. The new SFTP fix introduced uint64_t
and uint32_t, which aren't in C90. Please hold off releasing for now.

I've pushed a fix for the build failure, and added more versions of VS
to Appveyor so that we catch this automatically next time. It turned
out that only uint64_t was problematic, because we define uint32_t to
int.

I've also finally resurrected my old test suite that was really good
at catching SFTP stream errors. It confirmed that commit
d754fee2f24565d8c89dc37a7f05ba1222a7bfc4 introduced data corruption,
and that it has been fixed in latest master. So I think we're good to
go for a release now.

Alex

[Daniel Stenberg]

So I think we're good to go for a release now.

I'm scheduling the release to happen on February 23. That is Tuesday next
week. Gives us a few more days to run tests and if possible correct obvious
bugs.

The most recent packages found at http://libssh2.org/snapshots/ are then what
the release will look like in case anyone wants to get a "release candidate"
for a spin.

[Alexander Lamaison]

On 19 February 2016 at 16:08, George Garner (online)

It turned out that only uint64_t was problematic, because we define
uint32_t to int. <

I hope that you mean that you defined uint32_t to unsigned int!

Yes, indeed I did.