[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sftp_async_read_begin + uint32_t


On Tue, 2017-11-14 at 12:31 +0100, Andreas Schneider wrote:
> On Tuesday, 14 November 2017 12:08:06 CET Nikos Mavrogiannopoulos
> wrote:
> > Hi,
> 
> Hi,
> 
> >  While adding support of libssh to curl, I stumbled on the
> > sftp_async_read_begin and sftp_async_read APIs. Both accept file
> > size as uint32_t instead of size_t. In SCP or the other SFTP APIs,
> > there is no such limitation. Is that limitation intentional?
> 
> this shouldn't really be a problem as you should read in junks. The
> sizes of 
> those chunks should be 16k, 32k, ... Using chunks of more than 4GB
> doesn't 
> really make sense.
> 
> So you're saying curl uses chunks bigger than 4GB?

I guess not. It initializes transfer, where I was calling the
async_begin() and then uses repeated calls to the async_recv().

I've modified the patch [0] to keep a state in the receive function
and call async_begin() and async_recv() when needed. Thank you.

regards,
Nikos

[0].
https://github.com/curl/curl/pull/2036


References:
sftp_async_read_begin + uint32_tNikos Mavrogiannopoulos <nmav@xxxxxxxxxx>
Re: sftp_async_read_begin + uint32_tAndreas Schneider <asn@xxxxxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org