I found an undocumented public function and we can't have it like
that. The description here is incomplete, but should serve as a template
to allow filling in...
The sftp_write function shouldn't assume that the buffer pointer will be
the same in subsequent calls, even if it assumes that the data already
passed in before haven't changed.
The sftp structs are now moved to sftp.h (which I forgot to add before)
sftp_write was rewritten to split up outgoing data into multiple packets
and deal with the acks in a more asynchronous manner. This is meant to
help overcome latency and round-trip problems with the SFTP protocol.
Neither _libssh2_channel_write nor sftp_write now have the 32500 size
limit anymore and instead the channel writing function now has its own
logic to send data in multiple calls until everything is sent.
The new function takes two data areas, combines them and sends them as a
single SSH packet. This allows several functions to allocate and copy
less data.
I also found and fixed a mixed up use of the compression function
arguments that I introduced in my rewrite in a recent commit.
We now allow libssh2_session_flag() to enable compression with a new
flag and I added documentation for the previous LIBSSH2_FLAG_SIGPIPE
flag which I wasn't really aware of!
As a zero return code from channel_read() is not an error we must make
sure that the SCP functions deal with that properly. channel_read()
always returns 0 if the channel is EOFed already so we check for EOF
after 0-reads to be able to return error properly.
In the transport functions we avoid a strcmp() now and just check a
boolean instead.
The compress/decompress function's return code is now acknowledged and
used as actual return code in case of failures.
The function libssh2_session_startup() is now considered deprecated due
to the portability issue with the socket argument.
libssh2_session_handshake() is the name of the replacement.
When a call to _libssh2_transport_write() succeeds, we must return from
_libssh2_channel_write() to allow the caller to provide the next chunk
of data.
We cannot move on to send the next piece of data that may already have
been provided in this same function call, as we risk getting EAGAIN for
that and we can't return information both about sent data as well as
EAGAIN. So, by returning short now, the caller will call this function
again with new data to send.
Replaced -1/SOCKET_NONE errors with appropriate error defines instead.
Made the verbose trace output during banner receiving less annoying for
non-blocking sessions.
In an attempt to make the trace output less cluttered for non-blocking
sessions the error function now avoids calling the debug function if the
error is the EAGAIN and the session is non-blocking.
LIBSSH2_SOCKET_NONE (-1) should no longer be used as error code as it is
(too) generic and we should instead use specific and dedicated error
codes to better describe the error.
The well known and used ssh server Dropbear has a maximum SSH packet
length at 32768 by default. Since the libssh2 design current have a
fixed one-to-one mapping from channel_write() to the packet size created
by transport_write() the previous limit of 32768 in the channel layer
caused the transport layer to create larger packets than 32768 at times
which Dropbear rejected forcibly (by closing the connection).
The long term fix is of course to remove the hard relation between the
outgoing SSH packet size and what the input length argument is in the
transport_write() function call.
When parsing the SCP protocol and verifying that the data looks like a
valid file name, byte values over 126 must not be consider illegal since
UTF-8 file names will use such codes.
Reported by: Uli Zappe
Bug: http://www.libssh2.org/mail/libssh2-devel-archive-2010-08/0112.shtml
