With the new sftp based scp, using scp to copy a file over itself, truncates that file: Steps to Reproduce: 1. echo foo > /tmp/bar 2. scp /tmp/bar $(hostname):/tmp/bar 3. cat /tmp/bar All data in that file is then lost. This is a problem for scripts, e.g. cluster automation tools that rely on the fact that a file /tmp/bar can be copied with scp to all cluster nodes as /tmp/bar, including the node itself. Changing this behavior is unexpected, and silently dropping the data seems to be the worst possibly outcome. In addition to scripts, admins might also be surprised that copying files (maybe accidentally) to the same host, leaves those files corrupted. Would it be possible to change the behavior in this case? Either explicitly returning an error, or finding a way to preserve the data would be a better outcome. https://lists.mindrot.org/pipermail/openssh-unix-dev/2022-February/040059.html suggests that possibly the sftp server could use a temp file.
Not sure that assignment to an external contributor is a good idea :)
Created attachment 3594 [details] don't overwrite files This fixes it for 'scp foo localhost:foo' and 'scp localhost:foo foo', but not 'scp localhost:foo localhost:foo'
This fix has been committed and will be in OpenSSH 9.1, due in a few months. commit 56a0697fe079ff3e1ba30a2d5c26b5e45f7b71f8 (HEAD -> master, origin/master, origin/HEAD) Author: djm@openbsd.org <djm@openbsd.org> Date: Fri May 13 06:31:50 2022 +0000 upstream: arrange for scp, when in sftp mode, to not ftruncate(3) files early previous behavious of unconditionally truncating the destination file would cause "scp ~/foo localhost:" and "scp localhost:foo ~/" to delete all the contents of their destination. spotted by solene@ sthen@, also bz3431; ok dtucker@ OpenBSD-Commit-ID: ca39fdd39e0ec1466b9666f15cbcfddea6aaa179
Closing bugs from openssh-9.1 release cycle
OpenSSH 9.3 has been released. Close resolved bugs