Many of my customers use the PuTTY suite of secure remote access tools (mostly on Windows), and I've written about it here:
Tech Tip: Secure Linux/UNIX access with PuTTY and OpenSSH
PuTTY is great, but I made an unnerving discovery this weekend about PSFTP.
PSFTP is the SFTP client, which is sort of like FTP over SSH, and it allows for secure file transfers between the local machine and the remote server. Most of the time it's used interactively by a human, but it also supports a batch file option to run a bunch of commands all as a group, and it's often used to automate repeated file-transfer tasks (say, to upload a file to another server every night).
The unnerving discovery is that though PSFTP produces error messages during batchfile processing, the program's exit code is always "success" even if things went wrong. This means that the calling script has no real way of knowing that it didn't work.
Network or login errors do reflect an error exit status, but once it starts processing the batchfile, it's only going to exit with success status even if batchfile commands fail. Even a missing batchfile still causes a success exit code.
I suppose one way to deal with this is to parse the program's output looking for known error messages, but this is terribly unreliable, and is no substitute for PSFTP properly reflecting success or failure in the exit status: if anything goes wrong, the calling script should know about it so it can take some action (usually to notify somebody to have a look).
Note that the -be command-line parameter, which says to exit batch processing on error, doesn't impact the program's exit code.
This came as a total surprise, and in my application it mattered a lot because the calling script had to know if the file transferred or not. Needing this functionality, I created a patch against PSFTP.C that introduces a -batchfail command-line option that causes errors during batch file processing to exit with error status (if this option is not provided, there's no visible change in PSFTP's behavior).
This has been working well for me in my application, and I've submitted this patch to PuTTY's maintainers for consideration; I'm hoping they either accept it, or at least give some guidance on how I can make it better (and in the spirit of the rest of the code). The patch is against the current production release, v0.62.
psftp-batchfail-patch.txt
I'd sure love feedback among those who try this.





cant this issue be gotten around by simply using PSCP instead, which does return errorlevel of zero only if successful?
PSCP returns an ERRORLEVEL of zero (success) only if the files were correctly transferred.
[Not all SFTP servers are configured to allow SCP, and the two unrelated servers I was working with were of this type, and were not something I could change -- SJF]
Posted by: s h | July 25, 2012 at 03:50 PM
The developer of rssh quit the development of rssh two years ago. I wouldn’t recommend to use rssh since security issues won’t be fixed. Better use scponly…
Posted by: ios developers | October 18, 2012 at 09:50 PM
Thanks for the patch. I have similar problem and your patch helped me.
Posted by: Ge | October 30, 2012 at 03:56 AM
I worked around this by having the last step of my command file execute a local command to create an empty local file. My script that calls psftp then checks for that file.
Posted by: J.R. | November 20, 2012 at 09:43 AM