[Bug 4049] New: scp leaves a truncated destination file on ENOSPC (no atomic replace)

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=4049

            Bug ID: 4049
           Summary: scp leaves a truncated destination file on ENOSPC (no
                    atomic replace)
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: scp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: gabrielcharib at gmail.com

Hi,

I hit this while copying what was effectively a database dump with scp.
The destination volume filled up mid-transfer. scp did fail (exit
status 1)
and printed "No space left on device", which is good — but it left a
partial file at the final destination path.

So if a script only checks "does the remote file exist?", it can look
like
the copy succeeded even though the file is truncated. That is easy to
miss
in ops/backup workflows.

This feels related to bug 1703 (atomic replace on upload). I also
looked
through older ENOSPC-related history (2028 / 403 / 639). I could not
find
an open bug that clearly describes: ENOSPC + truncated leftover file at
the final name with current scp.

I’m not asking for scp to grow a built-in SHA-256 feature. The painful
part is simply that an incomplete file remains under the real
destination
name.

-------------------------------------------------------------------
Versions
-------------------------------------------------------------------
Client:
  OpenSSH_8.9p1 Ubuntu-3ubuntu0.18, OpenSSL 3.0.2 15 Mar 2022
  Ubuntu 22.04.5 LTS (x86_64)

Server for the repro:
  linuxserver/openssh-server container (reported as 10.3_p1-r1-ls240)
  destination on an 8 MiB tmpfs with about 1 MiB free

-------------------------------------------------------------------
How reproducible
-------------------------------------------------------------------
Always, as long as free space < source size.

-------------------------------------------------------------------
Steps to reproduce
-------------------------------------------------------------------
1. Make a destination with very little free space
   (I used an 8 MiB tmpfs, pre-filled down to ~1 MiB free).
2. Create a larger source file:
     dd if=/dev/urandom of=source-dump.bin bs=1M count=30
     sha256sum source-dump.bin
3. Copy it:
     scp source-dump.bin user at host:upload/source-dump.bin
4. Check exit code, stderr, destination size, and checksums.

----------------------------------------------------------------------
What happened
-----------------------------------------------------------------------
- Exit status: 1
- stderr:
    scp: upload/source-dump.bin: No space left on device
- Destination file still there, but truncated:
    source: 31457280 bytes
    dest:    1048576 bytes
- Different SHA-256:
    source:
6e9bbc0e8c93fb034e92fe0e1b0b768ee278b097795944eb0163fb2ad2407171
    dest:  
251b74fd254eda16e339e735ae5671fef12b71a463b8fa0117d71bd0d32cb8d9
- Destination FS ended up 100% full

------------------------------------------------------------------
What I would expect
------------------------------------------------------------------
Any of these would help a lot:
1. On ENOSPC, don’t leave a half-written file under the final name
   (delete it, or keep a temp name only), and/or
2. Atomic replace (temp file + rename), as in bug 1703, and/or
3. Clear docs that scp writes in place and may leave a truncated file
   after failure, so callers should verify size/integrity as well as
   the exit status.

-------------------------------------------------------------------
Extra context
-------------------------------------------------------------------
In practice this showed up around database dump copies: after a failed
transfer you can still see “a file” on the remote host and assume the
dump is complete.

Workaround for now: rsync, or wrap scp with free-space checks + exit
code + size/sha256 verification, and delete the destination on failure.

Happy to attach a short repro note (commands + measured sizes/hashes)
if that helps.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.