RCSID("$OpenBSD: scp.c,v 1.113 2003/11/23 23:21:21 djm Exp $"); Part of the OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003 distribution Could someone verify this case we found that causes a file to be missed during copying? Not copying a file without any error indication is a major problem. Here is the setup to replicate the problem: On hosta /tmp: -rwxrwxr-x 1 rdpecken rgr00rdp 12054 Apr 13 07:46 do_tie_configs -rwxrwxr-x 1 rdpecken rgr00rdp 9421 Apr 15 07:58 force_download -rwxrwxr-x 1 rdpecken rgr00rdp 9564 Apr 15 07:59 load_test_config -rwxrwxr-x 1 rdpecken rgr00rdp 7344 Apr 15 08:07 run_mgdiffs ****** -rwxrwxr-x 1 rdpecken rgr00rdp 5287 Nov 12 12:39 save_new_config ****** -rwxrwxr-x 1 rdpecken rgr00rdp 7580 Apr 15 08:54 save_new_tie ****** -rwxrwxr-x 1 rdpecken rgr00rdp 7600 Apr 15 08:02 save_tie_files -rwxrwxr-x 1 rdpecken rgr00rdp 1945 Feb 25 09:47 tie_build_setup_r10 -rwxrwxr-x 1 rdpecken rgr00rdp 7384 Apr 15 08:25 tie_dbgen_build -rwxrwxr-x 1 rdpecken rgr00rdp 7354 Apr 15 08:03 tie_setup On hostb /tmp: ****** -rwxrwxr-x 1 rgrmas rgrusr 5287 Apr 27 08:34 save_new_config ****** -rwxrwxr-x 1 bowtie rgrusr 7600 Apr 15 08:02 save_tie_files cd /tmp scp -p hosta:/tmp/[a-z]** . do_tie_configs 100% 12KB 11.8KB/s 00:00 force_download 100% 9421 9.2KB/s 00:00 load_test_config 100% 9564 9.3KB/s 00:00 run_mgdiffs 100% 7344 7.2KB/s 00:00 ****** save_new_config 100% 5287 5.2KB/s 00:00 ./save_new_config: set mode: Not owner ./save_new_config: set times: Not owner ****** save_tie_files 100% 7600 7.4KB/s 00:00 tie_build_setup_r10 100% 1945 1.9KB/s 00:00 tie_dbgen_build 100% 7384 7.2KB/s 00:00 tie_setup 100% 7354 7.2KB/s 00:00 The resulting files are: ****** -rwxrwxr-x 1 rgrmas rgrusr 5287 Apr 27 08:34 save_new_config ****** -rwxrwxr-x 1 bowtie rgrusr 7600 Apr 15 08:02 save_tie_files The question is why was the file "save_new_tie" not copied? It didn't even show up in the progress report above? It appears as if scp skips the following file after a previous file error. Thanks - Andy
I can't reproduce it here on Linux (with bash). Maybe the problem is related to shell expansion? What shell are you using at both ends? Try echoing the command locally and via ssh and see what it expands to: echo scp -p hosta:/tmp/[a-z]** . ssh hosta "echo scp -p hosta:/tmp/[a-z]** ." Does this work as expected? scp -p 'hosta:/tmp/[a-z]*' .
OK, I take it back, I can reproduce it thusly: $ cd /tmp $ mkdir tmp1 tmp2 $ touch tmp1/test1 tmp1/test2 tmp2/test1 $ sudo chown root tmp2/test1 $ cd tmp2 $ scp -p localhost:/tmp/tmp1/* . test1 100% 0 0.0KB/s 00:00 ./test1: set mode: Operation not permitted ./test1: set times: Operation not permitted $ ls test1 It looks like the problem is that in this particular path, run_err() gets called twice, so as soon as the following file transfer starts it get the second of the error messages.
Created attachment 664 [details] set flag to prevent double-error Please try this patch and see if it solves your problem.
Created attachment 669 [details] Equivalent patch against OpenBSD
Created attachment 670 [details] Regression test for this problem (against OpenBSD).
Our apps group re-ran the original scripts that detected the problem and scp functioned as expected. Thanks for resolving the problem.
This is now fixed in -current, and the fix will be in tomorrow's snapshot. Thanks for the report.