Hello,
There appears to be a problem doing SFTP reads with the latest code in
CVS. I used the samples "example/simple/sftp_nonblock.c" and "example/
simple/sftp.c"for these results. Trying to read buffers larger than a
kilobyte (1393 bytes seems to be the cutoff - memory smasher?) causes
Hello,
There appears to be a problem doing SFTP reads with the latest code in
CVS. I used the samples "example/simple/sftp_nonblock.c" and "example/
simple/sftp.c"for these results. Trying to read buffers larger than a
kilobyte (1393 bytes seems to be the cutoff - memory smasher?) causes
MAC val
st to make total_num unsigned, but if
this isn't possible for some reason, then it should be explicitly cast
as unsigned or checked for a negative value whenever it used.
Regards,
Lucas
On Feb 11, 2007, at 11:25 PM, Lucas Newman wrote:
> Hello,
>
> There appears to be a probl
2007, at 3:59 PM, Lucas Newman wrote:
> As a followup to the bug I reported yesterday, I have found some more
> issues in the packet handling with the latest code in CVS. For one,
> in the transportpacket structure, the total_num field is an integer,
> so if the packet is corrupted (this
Daniel Stenberg wrote:
> On Mon, 12 Feb 2007, Lucas Newman wrote:
>
>> I think I understand what is happening now. If a large read blocks
>> in the middle, the chunk of data obtained is processed in
>> transport.c to determine if a full packet was snagged. While
/* advance write pointer */
p->wptr += numbytes;
/* increse data_num */
p->data_num += numbytes;
On Feb 13, 2007, at 2:52 PM, Daniel Stenberg wrote:
> On Tue, 13 Feb 2007, Lucas Newman wrote:
>
>> This loop w
And I just realized that it was an earlier version of the patch which
subtracted from the write index, so ignore me :) I would like
feedback on the patch though.
-Lucas
On Feb 13, 2007, at 3:49 PM, Lucas Newman wrote:
> Here's a patch that addresses it. You may want to do it dif
I've noticed that the new sftp_readnb and sftp_writenb functions don't
ever seem to block. I profiled the libssh2_sftp_nonblock sample and I
am seeing half of the time still spent blocking, even when doing the
largest reads possible.
Looking through the code, I think the reason is because
d the spec declares that
the current max size only be supported, not that it must be the
largest size supported.
On Feb 27, 2007, at 1:01 PM, Daniel Stenberg wrote:
> On Tue, 27 Feb 2007, Lucas Newman wrote:
>
>>> For the *readnb() case, we need to rip out usage of the
>>&
On Apr 16, 2007, at 1:11 PM, Daniel Stenberg wrote:
> There was no (proper) support for non-blocking operations in the
> past so this
> function obviously didn't set non-blocking in the sense I would
> think it
> means. Actually, after having read the docs in the libssh2.org wiki,
> I simply
On Apr 22, 2007, at 2:52 PM, James Housley wrote:
> I think maybe we should remove the *nb() functions and make the old
> names just work. I would also like to keep old programs working in
> all cases, as long as they didn't set non-blocking to true (since we
> know that didn't work). But before
11 matches
Mail list logo
