[Bug 794] scp2 copy from machine A (openssh 3.5p1) to B (ssh 2.4.0) causes transferred file to be empty

[bugzilla-daemon at mindrot.org]

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.