bugzilla-daemon at mindrot.org
2004-Jan-23 22:46 UTC
[Bug 794] scp2 copy from machine A (openssh 3.5p1) to B (ssh 2.4.0) causes transferred file to be empty
http://bugzilla.mindrot.org/show_bug.cgi?id=794 Summary: scp2 copy from machine A (openssh 3.5p1) to B (ssh 2.4.0) causes transferred file to be empty Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-bugs at mindrot.org ReportedBy: storri at torri.org 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 at 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. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2004-Jan-23 22:51 UTC
[Bug 794] scp2 copy from machine A (openssh 3.5p1) to B (ssh 2.4.0) causes transferred file to be empty
http://bugzilla.mindrot.org/show_bug.cgi?id=794 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From mouring at eviladmin.org 2004-01-23 15:51 ------- 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 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2004-Jan-23 23:14 UTC
[Bug 794] scp2 copy from machine A (openssh 3.5p1) to B (ssh 2.4.0) causes transferred file to be empty
http://bugzilla.mindrot.org/show_bug.cgi?id=794 ------- Additional Comments From dtucker at zip.com.au 2004-01-23 16:14 ------- (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). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.