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@mindrot.org
ReportedBy: storri@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@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.
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@mindrot.org
ReportedBy: storri@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@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.