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