[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sftp_async_read_begin + uint32_t
[Thread Prev] | [Thread Next]
- Subject: Re: sftp_async_read_begin + uint32_t
- From: Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Tue, 14 Nov 2017 14:14:43 +0100
- To: libssh@xxxxxxxxxx
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
sftp_async_read_begin + uint32_t | Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx> |
Re: sftp_async_read_begin + uint32_t | Andreas Schneider <asn@xxxxxxxxxxxxxx> |