openssh unix dev - May 2001 - scp: Problem when source and destination are identical

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.

-- 
Florian Weimer 	                  Florian.Weimer at RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

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>

On Thu, May 17, 2001 at 04:54:27PM +0200, Florian Weimer
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.
how should rcp/scp know that the files are identical?

It would be interesting to know how rcp is able to handle this...
With AIX:
myhost / # rcp -p /tmp/txt myhostInterfaceB:/tmp/txt
rcp: /tmp/txt and /tmp/txt refer to the same file (not copied).
(Solaris-rcp doesn't complain like this, but the file remains intact...)
Someone with access to the AIX-Sources ???? ;-)
J?rg

-----Original Message-----
Markus Friedl <markus.friedl at informatik.uni-erlangen.de> writes:
> On Thu, May 17, 2001 at 04:54:27PM +0200, Florian Weimer 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.
> 
> how should rcp/scp know that the files are identical?

does this help:


Index: scp.c
==================================================================RCS file:
/home/markus/cvs/ssh/scp.c,v
retrieving revision 1.70
diff -u -r1.70 scp.c
--- scp.c	2001/05/08 19:45:24	1.70
+++ scp.c	2001/05/18 19:31:07
@@ -777,7 +777,7 @@
 		}
 		omode = mode;
 		mode |= S_IWRITE;
-		if ((ofd = open(np, O_WRONLY | O_CREAT | O_TRUNC, mode)) < 0) {
+		if ((ofd = open(np, O_WRONLY | O_CREAT , mode)) < 0) {
 bad:			run_err("%s: %s", np, strerror(errno));
 			continue;
 		}

this restores the rcp behaviour.


Index: scp.c
==================================================================RCS file:
/home/markus/cvs/ssh/scp.c,v
retrieving revision 1.70
diff -U10 -r1.70 scp.c
--- scp.c	2001/05/08 19:45:24	1.70
+++ scp.c	2001/05/18 19:38:58
@@ -770,21 +770,21 @@
 					    vect[0], strerror(errno));
 			}
 			if (mod_flag)
 				(void) chmod(vect[0], mode);
 			if (vect[0])
 				xfree(vect[0]);
 			continue;
 		}
 		omode = mode;
 		mode |= S_IWRITE;
-		if ((ofd = open(np, O_WRONLY | O_CREAT | O_TRUNC, mode)) < 0) {
+		if ((ofd = open(np, O_WRONLY | O_CREAT , mode)) < 0) {
 bad:			run_err("%s: %s", np, strerror(errno));
 			continue;
 		}
 		(void) atomicio(write, remout, "", 1);
 		if ((bp = allocbuf(&buffer, ofd, 4096)) == NULL) {
 			(void) close(ofd);
 			continue;
 		}
 		cp = bp->buf;
 		wrerr = NO;
@@ -825,21 +825,21 @@
 				cp = bp->buf;
 			}
 		}
 		if (showprogress)
 			progressmeter(1);
 		if (count != 0 && wrerr == NO &&
 		    (j = atomicio(write, ofd, bp->buf, count)) != count) {
 			wrerr = YES;
 			wrerrno = j >= 0 ? EIO : errno;
 		}
-#if 0
+#if 1
 		if (ftruncate(ofd, size)) {
 			run_err("%s: truncate: %s", np, strerror(errno));
 			wrerr = DISPLAYED;
 		}
 #endif
 		if (pflag) {
 			if (exists || omode != mode)
 				if (fchmod(ofd, omode))
 					run_err("%s: set mode: %s",
 					    np, strerror(errno));

On Fri, 18 May 2001, Markus Friedl wrote:
> -		if ((ofd = open(np, O_WRONLY | O_CREAT | O_TRUNC, mode)) < 0) {
> +		if ((ofd = open(np, O_WRONLY | O_CREAT , mode)) < 0) {
If you do that, you need to uncomment the ftrunctate() call lower down
(or overwriting a larger file with a shorter one will leave spurious
data at the end).

..wayne..