Shell Programming and Scripting

The manual pages refer to internal SFTP commands only. You are escaping to the shell on your local machine, so SFTP doesn't care what happens to it. This will try to delete the local file, which may be what you want, but you would be better closing the SFTP connection and then doing the remove of the local file in your shell script, where you can then test the return code.

Something like:-

Code:

$ cat sftp.cmnds
put localfile remotefile

$ cat myscript.sh
#!/bin/ksh
sftp a@b -b sftp.cmnds
RC=$?
if [ $RC -ne 0 ]
then
   ## Handle SFTP failure ##
else
   rm localfile
   RC=$?
   if [ $RC -ne 0 ]
   then
      ## Handle local file deletion error ##
   fi
fi

Does that help?


Robin
Liverpool/Blackburn
UK

This is what i first came up with, but there seems to be a problem when doing this.
Since it is a large amount of files the script makes a lot of different sftp connections. After an upgrade of the 3rth party server we are having many issues with sftp failures. Therefore i was charged to change the scripts so all files get sent over 1 sftp connection. (this way we avoid so many failures)
So bottom line, setting up a different connection for every file is out of the question.

(sorry i'm so difficult, but if it was easy i wouldn't have posted it ;-) )

As I mentioned in an edit above, can you do a pull rather than a push? Then you could use sftp's internal rm, and it would abort on fail.

Ah. That rather shoots my suggestion out the water. I suppose you have already exhausted trying to find out why the SFTP doesn't always work.

You could have a retry loop to allow up to 5 failed attempts perhaps? Or, could you sleep for a second in between? I suppose that if there really are lots of files then that could add considerable time, so could you sleep for a second every 5 SFTPs? I suppose it depends on how frequently you get a failure.

Could it be a DNS/IP lookup issue at the remote server perhaps?


Okay, I'm probably waffling on about stuff you've already tried. Never mind.

I will keep thinking.



Robin
Liverpool/Blackburn
UK

that would indeed work, only as i mentioned before, the 3rd party server is a black box to us :-) (no possibility of getting scripts on it either )

---------- Post updated at 03:35 PM ---------- Previous update was at 03:33 PM ----------

Indeed as you said, we have given up trying to figure out why it fails (not much help from 3rd party either). Their final answer was, we do not see any problems on our side.

It would be so much nicer, however then you would need to change firewall settings to allow the other end to open a connection to your server and the potential risks there. I think you are right to dismiss SSH driving an SFTP back to you to do a get and rm as an option.



I see you have the usual "We're okay." type response. There must be a logging somewhere to say that the connection is refused, dropped, whatever. This is laziness on their side, especially if they made the change that broke it. I agree with your


No thoughts yet. Perhaps at 3am I will get an "A-ha!" moment.



Robin
Liverpool/Blackburn
UK

Just to clarify, sftp -b isn't aborting on a failed put either?