| .TH libssh2_sftp_write 3 "1 Jun 2007" "libssh2 0.15" "libssh2 manual" |
| .SH NAME |
| libssh2_sftp_write - write SFTP data |
| .SH SYNOPSIS |
| .nf |
| #include <libssh2.h> |
| #include <libssh2_sftp.h> |
| |
| ssize_t libssh2_sftp_write(LIBSSH2_SFTP_HANDLE *handle, |
| const char *buffer, |
| size_t count); |
| .SH DESCRIPTION |
| \fBlibssh2_sftp_write(3)\fP writes a block of data to the SFTP server. This |
| method is modeled after the POSIX write() function and uses the same calling |
| semantics. |
| |
| \fIhandle\fP - SFTP file handle as returned by \fIlibssh2_sftp_open_ex(3)\fP. |
| |
| \fIbuffer\fP - points to the data to send off. |
| |
| \fIcount\fP - Number of bytes from 'buffer' to write. Note that it may not be |
| possible to write all bytes as requested. |
| |
| \fIlibssh2_sftp_handle(3)\fP will use as much as possible of the buffer and |
| put it into a single SFTP protocol packet. This means that to get maximum |
| performance when sending larger files, you should try to always pass in at |
| least 32K of data to this function. |
| |
| .SH WRITE AHEAD |
| Starting in libssh2 version 1.2.8, the default behavior of libssh2 is to |
| create several smaller outgoing packets for all data you pass to this function |
| and it will return a positive number as soon as the first packet is |
| acknowledged from the server. |
| |
| This has the effect that sometimes more data has been sent off but isn't acked |
| yet when this function returns, and when this function is subsequently called |
| again to write more data, libssh2 will immediately figure out that the data is |
| already received remotely. |
| |
| In most normal situation this should not cause any problems, but it should be |
| noted that if you've once called libssh2_sftp_write() with data and it returns |
| short, you MUST still assume that the rest of the data might've been cached so |
| you need to make sure you don't alter that data and think that the version you |
| have in your next function invoke will be detected or used. |
| |
| The reason for this funny behavior is that SFTP can only send 32K data in each |
| packet and it gets all packets acked individually. This means we cannot use a |
| simple serial approach if we want to reach high performance even on high |
| latency connections. And we want that. |
| .SH RETURN VALUE |
| Actual number of bytes written or negative on failure. |
| |
| If used in non-blocking mode, it returns LIBSSH2_ERROR_EAGAIN when it would |
| otherwise block. While LIBSSH2_ERROR_EAGAIN is a negative number, it isn't |
| really a failure per se. |
| |
| If this function returns 0 (zero) it should not be considered an error, but |
| simply that there was no error but yet no payload data got sent to the other |
| end. |
| .SH ERRORS |
| \fILIBSSH2_ERROR_ALLOC\fP - An internal memory allocation call failed. |
| |
| \fILIBSSH2_ERROR_SOCKET_SEND\fP - Unable to send data on socket. |
| |
| \fILIBSSH2_ERROR_SOCKET_TIMEOUT\fP - |
| |
| \fILIBSSH2_ERROR_SFTP_PROTOCOL\fP - An invalid SFTP protocol response was |
| received on the socket, or an SFTP operation caused an errorcode to |
| be returned by the server. |
| .SH SEE ALSO |
| .BR libssh2_sftp_open_ex(3) |