scp2 not completely overwriting a file?

[Scott Newman]

I am seeing a behavior that I am having a hard time believing. I searched and did not see any references, but I find it hard to believe I am the first to see it:

I have two Tru64 5.1B servers: let's call them srv1 and srv2. I have a file on srv2 called /tmp/junk that contains the text:

Hello World?

On srv1 I have a file called /tmp/junk that contains the text

Goodbye!

From srv1, if I execute

scp2 /tmp/junk user@srv2:/tmp/junk

I wind up with:

Goodbye!
ld?

(the first 9 characters of the target file are replaced with the 9 characters of the source file, including the newline, and the remaining 4 characters of the target file remain, including the newline)

Is this expected? What is the best way to ensure that the target file is completely overwritten (like in cp)?

[Steven Schweda]

I don't have two Tru64 systems handy, but on
one system talking to itself:

urtx# echo long-long-long > /tmp/sc_l
urtx# echo short > /tmp/sc_s

urtx# ls -l /tmp/sc_*
-rw-r--r-- 1 root system 15 Sep 14 11:03 /tmp/sc_l
-rw-r--r-- 1 root system 6 Sep 14 11:03 /tmp/sc_s

urtx# cat /tmp/sc_*
long-long-long
short

urtx# scp2 /tmp/sc_s root@urtx:/tmp/sc_l
root@urtx's password:
sc_s | 6B | 0.0 kB/s | TOC: 00:00:01 | 100%

urtx# ls -l /tmp/sc_*
-rw-r--r-- 1 root system 6 Sep 14 11:04 /tmp/sc_l
-rw-r--r-- 1 root system 6 Sep 14 11:03 /tmp/sc_s

urtx# cat /tmp/sc_*
short
short

That is, no problem.

urtx# sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Mon Feb 19 11:57:07 CST 2007

urtx# scp2 -V
scp2: SSH Secure Shell Tru64 UNIX 3.2.0

[Reto Kisseleff · Accepted solution]

Hi Scott

no, you're not the only one who discovered this problem.
There is a bug in scp2 which is fixed in Tru64 V5.1B-4 (PK6 BL27)
If you're running BL26 (PK5) there exist a patch which solves the problem.
(check with dupatch -track -type kit -nolog)

http://h30097.www3.hp.com/unix/erp/c00553244.html
PatchID: T64KIT1000096-V51BB26-E-20051110

cheers
Reto

[Scott Newman]

Reto: Thanks! I tried to research this issue and the descriptions were rather vague. All I saw was "Under certain
circumstances, scp2 or sftp2 can copy files incorrectly.". I was wondering if you saw any more specific information or if you encountered this behavior yourself.

Steven: Thanks for the effort. Do you have the patch the Reto mentions installed?

I will leave this thread open a little longer before awarding points and closing it out. Thanks again for the timely responses!

Scott

[Steven Schweda]

> [...] Do you have the patch the Reto
> mentions installed?

I have PK6 installed, which might explain
why my "sizer -v" output differs from yours.
Except that we haven't seen yours, so we
can't tell. If you want to do something
useful, you could see what _your_ "scp2 -V"
says, too, which might provide another clue.
"5.1B", while interesting, is not a very
complete description of your environment.

[Scott Newman]

Steven,

Here is what I have:

/]/usr/sbin/sizer -v
Compaq Tru64 UNIX V5.1B (Rev. 2650); Fri Nov 3 21:57:19 EST 2006
/]scp2 -V
scp2: SSH Secure Shell Tru64 UNIX 3.2.0

which looks like your values above...

But if you have PK6, that would be consistent with Reto's info above, and would explain why it works OK for you.

Thanks again for your timely assistance. I think I am going to get our systems patched and test it out. I will report back.

Scott

[Scott Newman]

All,

Just as a note for anyone else encountering the same problem, the workaround I am employing until I get the patch installed and tested is to execute:

ssh2 user@srv2 "rm /tmp/junk"

then to perform the copy.

I am curious about what other behaviors are associated with this patch, and under what "circumstances" the behaviors occur, so I could be sure that this workaround is valid.

Scott

[Steven Schweda]

> Here is what I have: [...]

Yeah. Sadly, terms like "V5.1B-4" are used
only for marketing, so if you want more
valuable info, you need to do something like:

/usr/sbin/dupatch -track -type patch_level | grep -i 'patch kit'

[Reto Kisseleff]

Hi Scott
as I've said, this is not a workaround, it's exactly the solution to your problem.
As I can remember correctly the problem with scp2 came into PK5. The problem was related how we copy files.... If you copy a smaller file to a bigger one which already exist, we didn't replace the file, we just wrote sequential to the file. So at the end we still have the rest of old content in the original bigger file. => which is fixed with mentioned early release patch.
sizer -v doesn't tell you on which patchlevel you stay. dupatch -track -type kit -nolog does it for you.

(sometimes we don't want to tell customers what bugs we've done exactly:)

cheers
Reto

[Scott Newman]

Using the syntax suggested by Steven above, I see that I do have PK5 installed, which is consistent with Reto's information.

Reto: I am sorry, I was unclear in my comments above. I was referring to my workaround (using ssh to remove the file before initiating the copy). I believe that your suggestion is the solution, I just am using my workaround until I can get to implementing the patch. Based on your subsequent comments, I am confident in my workaround until I can get the patch installed (hopefully this weekend).

I will leave this thread open until I get the patch installed and will confirm success.

Thank you both for your attention. I hope I am able to return the favor sometime.

Scott