wolfsftp: keep the remote file when resuming a put

[yosuke-wolfssl]

Problem

Two defects, both leaving a corrupted file at the destination.

Client (wolfSSH_SFTP_Put, f-11659): resume mode restores the saved offset
and seeks the local source forward, but still opens the destination with
WOLFSSH_FXF_TRUNC. Truncation is the open's job (draft-ietf-secsh-filexfer-02
section 6.3), so the prefix already uploaded is discarded; the first write then
lands at the nonzero offset, which section 6.4 defines as zero-filling the gap.
A reput yields a hole followed by the tail, with no error returned.

Windows server (surfaced by the new test): creationDisp |= ... combined
dwCreationDisposition values that CreateFileA documents as mutually
exclusive. WRITE|CREAT became CREATE_ALWAYS and truncated a destination the
client asked to keep; READ|WRITE|CREAT[|TRUNC] became
OPEN_EXISTING | CREATE_ALWAYS == OPEN_EXISTING, so it failed when the file was
absent and never truncated when asked to. The POSIX server maps each flag
separately and is unaffected.

Fix (src/wolfsftp.c)

TRUNC is added only when the write offset is zero. Dropping it alone would
still hole a missing or short destination, and would newly allow stale trailing
bytes on a longer one, so a new STATE_PUT_STAT_REMOTE validates first - the
same shape as OpenSSH's sftp_upload() resume branch, which stats the
destination and never sends TRUNC on a resume. It runs before the local open,
where the offset is consumed (WFSEEK, or the OVERLAPPED seed on Windows),
and does nothing unless the saved offset is nonzero, so a plain put costs no
extra round trip.

wolfSSH_SFTP_STAT() on the destination	Action
size equals the saved offset	resume, no TRUNC
size differs, or no size attribute	restart from 0 with TRUNC
WS_SFTP_STATUS_NOT_OK, WS_PERMISSIONS	restart from 0 with TRUNC
WS_WANT_READ / WS_WANT_WRITE	retry in place
any other failure	re-save the offset, cleanup, error propagates

STATE_PUT_LOOKUP_OFFSET also drops the offset when the local source is no
larger than it - OpenSSH's "destination file same size or larger" case - which
otherwise resumes into a zero-byte transfer that reports success. It uses the
SFTP_GetAttributes() available on every port, so no extra round trip.

The Windows disposition is now assigned, not OR'd:

if (reason & WOLFSSH_FXF_TRUNC)
    creationDisp = CREATE_ALWAYS;
else
    creationDisp = OPEN_ALWAYS;

WRITE|CREAT|APPEND, which OpenSSH's sftp sends for reput, now maps to
OPEN_ALWAYS, so a Windows wolfSSH server no longer destroys the destination
for an OpenSSH resume.

WS_SFTP_PUT_STATE carries the returned attributes; it is defined only in
wolfsftp.c, so there is no header or ABI change.

Tests (tests/api.c)

test_wolfSSH_SFTP_PutResume() is the first coverage of the resume path;
scripts/get-put.test already drives a plain put. Five cases, each checking the
destination byte-for-byte: resume onto a matching prefix, resume with the
destination deleted, resume with an offset that undershoots it, a plain put over
a longer destination, and a resume whose source is shorter than the offset. The
resume case stages a prefix unlike the source and expects it back untouched, so
a silent full re-upload fails the test. Excluded on Zephyr, which lacks the
hosted wrappers needed to stage the local source.

Verification

• gcc-13 -Werror sweep over 6 configs (default, sftp-only, scp-only,
  enable-all, smallstack, Zephyr defines): clean, no warnings.
• make check, macOS --enable-all: 11 pass, 1 skip, 0 fail
  (scripts/sftp.test and scripts/scp.test need the serial re-run; their
  parallel failure is a harness counter bug, unrelated to this change).
• Negative control: with the offset-validation hunk reverted, the new
  source-too-short case fails.

Not in this PR

• SFTP_STAT() does not surface the SSH_FX status, so WS_SFTP_STATUS_NOT_OK
  also covers SSH_FX_FAILURE and SSH_FX_OP_UNSUPPORTED. The restart branch
  is commented to say so; distinguishing them needs a new SFTP_STAT() return.
• Windows SSH_FXF_EXCL and SSH_FXF_APPEND are still unmapped (pre-existing,
  inside the same #if 0).
• The new state's want-read re-entry is not covered in-tree; the test client
  uses a blocking socket. Likewise the stat's permission-denied restart and its
  hard-error abort, both of which need a server that can fail a stat on demand.

[Copilot]

Pull request overview

This PR fixes a data-corruption bug in wolfSSH_SFTP_Put() when resuming an upload (reput): the destination file was previously opened with WOLFSSH_FXF_TRUNC unconditionally, which discarded the already-uploaded prefix and could silently produce a hole + tail.

Changes:

• Add a new STATE_PUT_STAT_REMOTE step to validate that the remote destination size matches the saved resume offset; otherwise reset the offset and restart from 0.
• Make remote open truncation conditional on starting offset (TRUNC only when offset is 0).
• Add test_wolfSSH_SFTP_PutResume() to validate correct behavior across resume and non-resume scenarios against the in-process echoserver.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/wolfsftp.c	Adds remote stat validation for resume offsets and makes truncation conditional on starting at offset 0 to prevent resumed-upload corruption.
tests/api.c	Adds a new API-level regression test covering resumed put behavior and ensuring correct remote file contents.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #1191

Scan targets checked: wolfssh-bugs, wolfssh-src

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Reported findings require changes before merge.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #1191

Scan targets checked: wolfssh-bugs, wolfssh-src

Fenrir result: Approved ✅

No new issues found in the changed files.

Advisory only — this automated result does not count as a GitHub approval.

Fenrir's latest completed scan found no issues; clearing the prior automated change request.