[Bug 452] sftp does not abort when commands given via -b fail

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Mon Dec 30 11:18:37 EST 2002


http://bugzilla.mindrot.org/show_bug.cgi?id=452





------- Additional Comments From cjwatson at debian.org  2002-12-30 11:18 -------
Robert Bihlmeyer <robbe at orcus.priv.at> added these comments and suggested the
following patch:

The following "-b" script should work if everything ran as documented:

  get the-remote-file
  rm the-remote-file

In the status quo it can incur dataloss (and did for me, aargh!) if
the get fails for some reason (e.g. disk full).

The appended patch fixes the some cases, and should point people in
the right direction. There are still more places where process_get
will return -1 (which will not lead to abort). Either all these get
changed to 1, or -- as it seems the intention is not to abort on every
error -- the manpage documents exactly in which cases an abort will
happen. The current situation is just bad.

I'd be most satisfied with a "abort on every miniscule error" switch,
akin to sh's -e.

diff -u openssh-3.5p1/sftp-int.c~ openssh-3.5p1/sftp-int.c
--- openssh-3.5p1/sftp-int.c~   2002-12-30 01:13:29.000000000 +0100
+++ openssh-3.5p1/sftp-int.c    2002-12-30 01:13:29.000000000 +0100
@@ -426,7 +426,7 @@
                        goto out;
                }
                printf("Fetching %s to %s\n", g.gl_pathv[0], abs_dst);
-               err = do_download(conn, g.gl_pathv[0], abs_dst, pflag);
+               err = do_download(conn, g.gl_pathv[0], abs_dst, pflag) ? 1 : 0;
                goto out;
        }

@@ -451,7 +451,7 @@

                printf("Fetching %s to %s\n", g.gl_pathv[i], abs_dst);
                if (do_download(conn, g.gl_pathv[i], abs_dst, pflag) == -1)
-                       err = -1;
+                       err = 1;
                xfree(abs_dst);
                abs_dst = NULL;
        }



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the openssh-unix-dev mailing list