Subject: Re: How to append to remote file?

Re: How to append to remote file?

From: Daniel Stenberg <>
Date: Mon, 6 Dec 2010 12:13:43 +0100 (CET)

On Wed, 24 Nov 2010, Mark Riordan wrote:

> I tried doing a libssh2_sftp_fstat_ex on the remote file to find its size,
> then seeking to the end of the file using libssh2_sftp_seek64. But
> libssh2_sftp_seek64 isn't a real seek. In this case, it causes subsequent
> calls to libssh2_sftp_write to write 0 bytes.
> Is there a real remote seek or append capability?

Each FXP_WRITE packet sent to the server includes the offset so there's no
real seek operation needed.

I first tought the difference between WRITE and APPEND would be that APPEND
would allow a client to write beyond the end of the file, but then I read the
following from the spec:

    The write will extend the file if writing beyond the end of the file.
    It is legal to write way beyond the end of the file; the semantics
    are to write zeroes from the end of the file to the specified offset
    and then the data. On most operating systems, such writes do not
    allocate disk space but instead leave "holes" in the file.

... so I don't really understand what APPEND is good for! ;-)

> At any rate, I eventually tried the LIBSSH2_FXF_APPEND approach and got the
> same problem.
> I used a different SSH client to append a file to the same OpenSSH server
> and it did work.

Ah, you mean you don't know _how_ it appended but it worked?

I don't see any specific handling for APPEND in the libssh2 code, so I really
wonder if it ever worked. The spec says APPEND "Force all writes to append
data at the end of the file." but since all packets include an offset and as
libssh2 doesn't adjust that offset to force it beyond end of existing file I
don't think it works correctly...

My gut reaction is that we should use APPEND only in the API and instead just
use FXP_WRITE operations and put them at the end of file by will instead.
Especially due to that comment about there being servers that don't adhere to
APPEND anyway.

Received on 2010-12-06