scp: Problem when source and destination are identical

Jim Knoble jmknoble at jmknoble.cx
Thu May 24 06:07:28 EST 2001


Circa 2001-May-18 15:07:34 -0700 dixit Jason Stone:

: > It would be interesting to know how rcp is able to handle this...
: 
: ssh.com's scp also successfully copies a file on top of itself.  OpenSSH
: opens the destination file O_TRUNC, while rcp and ssh.com scp don't.
: 
: In my opinion, opening the file O_TRUNC is the right thing to do because
: in the usual case (scp from one system to another), you expect the
: destination file to be truncated to 0 length before you start - you don't
: want to start copying a new file over and old one and then end up with a
: weird combination of both should the scp die in the middle....

But if you use O_TRUNC, then you get an incomplete file if scp dies in
the middle, and you lose the old one.

What i would much rather see is for the destination scp to write the
incoming file to a temporary file in the same directory, and then
rename() it to the destination file on a successful copy.

    For: Avoids problems with files copied onto themselves.  Avoids
         incomplete copies.  Atomic replacement of existing destination
         files.

Against: Requires enough space available on the destination filesystem
         to hold both the old and the new copy of each file; this could
         be a drawback for large files.

-- 
jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010523/3457cd55/attachment.bin 


More information about the openssh-unix-dev mailing list