On Sun, 4 Sep 2011, Alexander Lamaison wrote:
Note that you managed to post to the old list, so I'm now replying to both the
old and the current one.
> I've been having a problem where sftp_read return 0 (i.e. thinks its reached
> the end of the file) even though it has only partly transferred it. This is
> particularly noticeable when the 'file' is something like /dev/random that
> renders data very slowly. Earlier versions used to block in this case and
> wait for data. git bisect identifies this commit as the culprit:
> http://trac.libssh2.org/changeset/90b4b4073f34919aa72deff61a5c9bc188c47c95/libssh2
Are you sure that really is the culprit? I mean, does it truly get back to
working if you revert that change?
I just don't see how that change is related to the problem you describe...
> Daniel, can you run me through the logic for this change? For instance,
> what happens when (buffer_size*4) is <= already? Are we supposed to modify
> count here too? And, I'm feeling a bit dense right now: why is it buffer*4?
Sure!
First, buffer_size*4 is just picked more or less out of the air. The idea is
that when reading SFTP from a remote server, we send away multiple read
requests guessing that the client will read more than only this 'buffer_size'
amount of memory. So we ask for maximum buffer_size*4 amount of data so that
we can return them very fast in subsequent calls. (Feel free to experiment to
set it *2 or *6 or whatever.)
The particular change you're referring to was made because if you call
sftp_read() in a sequence like:
1. sftp_read(VERY_BIG_BUFFER);
2. sftp_read(VERY_SMALL_BUFFER);
... before this change, the 'count' variable could get wrapped in the second
call (as 'already' was then larger than buffer_size*4) and since count is
unsigned, it would turn into an insanly high value and just be very very
wrong.
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-09-04