scp: Problem when source and destination are identical

[Hank Leininger]

On 2001-05-17, Florian Weimer <Florian.Weimer at RUS.Uni-Stuttgart.DE> wrote:

> If the source and destination file are identical, the receiving scp
> truncates the file.  On the sending end, read() returns 0, and garbage
> is sent instead of actual data, and the receiving end puts it into the
> file, which at least confuses the users.

This comes up every now and then.  Except for the simple case where both
files are local, how's scp really to know?  Sure, scp localhost:foo ~/foo
*seems* like an obvious clash, but what if it isn't?  you or your sshd may
be running chrooted, or config options may have you ssh/scp into localhost
as a different user by default, or 'localhost' may be an alias for some
other box, or you may have some forwarder on port 22... 

All of these may sound a bit far-fetched, but that's just the point,  the
first time you need to do something like this you'll curse the fact that
the openssh developers tried and failed to think of everything, and you'll
be stuck in "Can't Get There From Here".

See an earlier thread about the same question:

http://marc.theaimsgroup.com/?t=98084090100002&r=1&w=2

...Now, to throw some fuel on the fire: is there any room (i.e. would the
way scp is done even allow) for the equivalent of the -i option for cp? 
("Overwrite file 'foo'? y/N") I'm betting not, and the right answer for
things like that is "use rsync over ssh instead of scp."

--
Hank Leininger <hlein at progressive-comp.com>