I have two computers, A and B for this discussion, which run two different versions of ssh. Computer A runs OpenSSH 3.5p1 (RedHat 9) and computer B runs (ssh 2.4.0 non-commercial version). The home directory for my user is handled by NFS. So my home directory is mounted via NFS to both A and B. So why am I bothering to use scp? I did not know these machines were connected via NFS. Yet there was a interesting bug in scp2 discovering in attempting the copy. So the file exists before the transfer: -bash-2.05b$ ls -l cs507.ps -rw-r--r-- 1 storri student 169557 Jan 23 16:32 cs507.ps So I do the transfer with scp2 from home directory on A to home directory on B: -bash-2.05b$ scp2 cs507.ps twist: storri@twist's password: cs507.ps | 0B | 0.0 kB/s | ETA: 1+23:05 | 0% -bash-2.05b$ So ok its a bit worrying that nothing was supposedly transfer. So what happened? Here is the status of the original file after running this command: -bash-2.05b$ ls -l cs507.ps -rw-r--r-- 1 storri student 0 Jan 23 16:39 cs507.ps Here is the bug. When the transfer fail, which it should not, the original file is empty. Now that is really wrong. When setting up the destination to receive the file scp truncates the destination file to zero lenght. However since the destination file is the same as the source file then it also truncating the source file. Therefore it destroys the data. Machine A ssh version: OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f Machine B ssh version: ssh: SSH Secure Shell 2.4.0 (non-commercial version) on i686-pc-linux-gnu I did a copy via scp2 from a openssh 3.5p1 box to another openssh 3.5p1 box where source and destination directory where the same connect via NFS. It also destroyed the contents of the file as described above.
There is no way to for sftp subsystem or scp to know that they are the same file. Try it with ftp, rcp, etc and you'll find the same behavior. - Ben
(Ben beat me to the update, but I thought I'd add my 2 cents anyway). Although it's nasty it's doing exactly what you told it to. The steps scp will take are (in approximate order): 1) open source file for read 2) connect to target system 3) truncate destination file 4) send source file 5) write destination file Because your source and destination are the same, it goes pear-shaped at point 3. I'm not sure what scp could do about it. If it used a temp file or unlinked the destination first, because scp is unprivileged there's no guarantee that file permissions, ownership or non-traditional filesystem metadata (like ACLs), could be restored (currently they'll remain unchanged). Perhaps the only advice I can offer is "don't do that" (or possibly "use rsync for that" since it will use temp files).
Mass change of RESOLVED bugs to CLOSED