SFTP multipart stat failure can truncate an existing target

[robjarawan]

Finding

Sftp.put treats every remote stat exception as evidence that the target is absent. During a transient stat failure, it opens the remote target for replacement, truncating an existing multipart destination before writing the current block.

Proof target

Only treat a confirmed not-found response as absence. Propagate other stat failures without opening or modifying the target. Add deterministic tests for transient failure and true absence.

Scope

Fork validation for PROTO-12.

[robjarawan]

I rechecked this against the current sender fix in #138 (84f3f2377f7c7abf00af2fa9fa9ffdac597a4ebf) and reproduced the corruption through Sender.send() with real Paramiko SFTP traffic.

The fixture uses a local socket pair and temporary files. I start with AAAABBBBCCCC at the destination and send xxxx into bytes 4–7. For the timeout case, the SFTP server delays the first file STAT reply by three seconds while the sender has timeout 1. I do not replace Sftp.put() or its exception handling.

expected after a failed stat: AAAABBBBCCCC, send returns 0
actual on current code:      \x00\x00\x00\x00xxxx, send returns 1

I also reproduce it with an SFTP failure status and a permission-denied status. Both buffered compatibility mode and pipelined mode are affected. The healthy existing-file and genuinely missing-file controls pass: 6 failed, 4 passed overall.

Basically, the delayed reply causes the real timeout to fire, the bare except treats that as a missing file, and the following wb open truncates the existing destination. The sender then reports that the four-byte block was sent successfully.

I am refreshing the minimal fix from the old #127: create the file only for a confirmed missing-file error, and propagate other failures. I will keep this follow-up based on #138 because that PR already fixes the separate healthy middle-block tail truncation. The regression also checks a second send after the temporary metadata failure clears.

The old upstream #1739 closed without merging. This is new running caller/protocol evidence for the existing fork issue; I am not reopening or posting anything upstream.

[robjarawan]

I finished the fork proof and fix in PR #147.

The same local Paramiko/Sender regression that produced 6 failed, 4 passed on #138 head now passes all 10 cases at runtime commit f810224c4. The focused SFTP/sender suite passes 14 tests, and the broader suite passes 352 passed, 1 skipped with Azure emulator tests excluded.

The temporary-failure cases now leave AAAABBBBCCCC untouched and return failure. Repeating the same send after the fault clears produces AAAAxxxxCCCC and returns success. A genuinely absent target is still created, and both SFTP modes retain their healthy behavior.

I based the PR on #138 so the existing healthy middle-block fix remains the control rather than being duplicated here. The SFTP production diff only distinguishes confirmed ENOENT from other stat() failures. The PR remains draft for flow CI and independent review.