return ftp status

Shell Programming and Scripting
1

Hello,

I still have problems when trying to figure out if the status of an ftp was successful. I ftp to different types (nt, vax, unix, etc...) of machines. I am trying to write a universal script that will ftp a file and then check to see if the ftp was successful. I have tried the following:

verify file sizes: VAX and UNIX boxes have different file sizes
grep ftp result for:
code 226; some boxes have different sayings

Do you have ideas?

Thanks,
Barbara

2

In this post, I show the best technique that I have found to get the return codes. It is imperfect, and I'd love to see a better idea. Because it's so hard to know how long to sleep, I usually take my best shot, then double it. This technique wastes a lot of clock time.

Yeah, there are several codes that can result from an operation failing. You will need to check for them all. But it's not like every programmer can make up his own codes or anything. The codes are documented in RFC 959. Any ftp server that returns different codes is broken.

For transfers, I would just look for the presense of a code 226. That would indicate that the transfer worked. No code 226, it must've failed. But if you want to diagnose the error, this won't be enough. It depends on how far you want to go.

Also, I don't understand why your file sizes are off. This sounds like you did an ascii transfer when you needed a binary transfer.

3

Hope this can help
ftp -v hostname
-v that will show all responses from the remote server, as well as report on data transfer statistics. This is turned on
by default if ftp is running interactively with its input coming from the user's terminal.

4

Thanks!

In the past, I have checked for "226". There have been some cases where the bytes transferred, bytes sent, or transfer time contains "226". The job result is successful, yet the ftp was not successful. So this doesn't always work for my scenario.

The translation of code 226 is not consistent on all boxes. For example, I have seen "226 Closing data connection" or "226 Transfer Complete" as a translation for code 226.

I do have -v in my ftp command line. Because the "226" code is not consistent, the status returned is not always reliable.

Thanks,
Barbara

5

The 226 is consistent. The text that follows it is not. As the rfc says:

If you get a 226 in response to a request for a transfer, the server is trying to tell you that it succeeded.

226 Transfer Complete
226 Closing Data Connection

mean almost the same thing. After a successful tranfer, the rfc allows a sever to keep a data connection open and re-use it for the next transfer. This is rarely done and the second message is underscoring that it wasn't done.

226 Everything's Groovy
226 That worked
226 looks good to me

would all be legal ways for a server to tell you that the transfer completed successfully. I've never seen anyone do that, but English is certainly not required by the rfc.

You really should read that RFC that I linked to in my earlier post. It will tell you what a server can and cannot do. The whole section on reply codes would especially help you out.

6

Thanks.

I'm sorry I guess I didn't explain myself correctly. This is my existing code:

  ftpresults=\`ftp -inv $ip\_box_name <<EOB
  user $userid $password
  put $ftp_file $downstream_name
  bye
  EOB\`

  ftp_ctr=\`echo "$ftpresults" | grep "226 Transfer complete" | wc -l\`
  echo $ftp_ctr
  if [ $ftp_ctr = 1 ]
  then
echo "FTP of " $file_name " to " $ip\_box_name " was successful"
echo " "
  else
ftp_error="true"
  fi

In my prior reply, I was trying to say that if I did a grep on "226" alone, a count of 1 would be returned if the bytes transferred were a size which contained "226". I am trying to find something in the return of the ftp to grep. This will allow me to tell me if it was successful. I read the codes that you had passed along in your prior response.

Thanks,
Barbara

7

Try:
grep "^226"

8

Instead of just grep, include another grep.

ftp_ctr=`echo "$ftpresults" |grep "226" | grep -v "byte" | wc -l`

This should take care of the "bytes transfered".

As far as VMS / UNIX file sizes, you would have to do some math but you could do it. (unfortunately, I don't quite remember what the VMS defaults are...too many UNIX commands to remember).

9

Hi
The whole issue is to do with the usual ftp that we use, i have had this problem before of automating the session coz my ftping process nearly takes 2 to 3 hours, so the monitoring process and consequently the restarting of the whole process if the ftping fails does become tedious and time consuming so even the above mentioned return code will not prove useful to me, the process needs to be completed without any active external intervention which only then become a complete automated process.

I used an ftp software called ncftp which actually returns the status of the connection.
These are the status codes that it returns
0. Success.
1- Could not connect to remote host.
2- Could not connect to remote host - timed out.
3- Transfer failed.
4- Transfer failed - timed out.
5- Directory change failed.
6- Directory change failed - timed out.
7- Malformed URL.
8- Usage error.
9- Error in login configuration file.
10- Library initialization failed.
11- Session initialization failed.

This will solve the problem.
I can include the code that i used,if required..

10

hi
some modifications are required believe me it works , ihave tested
the code u are using is same as i am using instead of greping it from standard output
try to put all the response from the server in a file and use fgrep instead of grep
fgrep will return the string if it find one and instead of taking 226 u can use
"221 GoodBye" which is returned when the connection is closed properly
i have personly used this and it is working fine

11

I can't understand why anybody insists in automating ftp. To use ftp for batch transmission of files is just using a tool out of its specification. Yes, it is possible to use it out of its specification a bit better, but why bother?

For automatic transmission of files use the r-commands, like rcp (for single files), rsnyc (for bulk transmissions) or the kerberized pendants - or even the s-versions (scp, etc.) if you must. Save for scp (which, like ssh, isn't all too well suited for scripting) they can easily be impemented in scripts, have reliable commandline interfaces, meaningful returncodes - what else do you want? And why do you want ftp to deliver it?

bakunin

12

We have service providers who deliver data to us. The only technique they support is FTP to their site. We have 6 of these and we need the data file each business day. We also provide data and our perferred method is via http. A few clients demand ftp service and we aren't going to turn them away. We also would use sftp where we can, but only one client has gone for that. sftp is not any eaisier to script. We would turn away business before we open the r-commands to the internet.

I am dismayed to learn that my scripts may be in violation of the ftp standards. What specification forbids automated ftp? I musta missed that as I read the rfc's...

13

Sorry, if i was a little harsh yesterday (haven't had the best of days), but the main point remains: ftp is a program built for interactive transmission of files. There are other programs built for batch transmission of files, which are a lot easier (and more reliable) to script and are overall better suited for the task.

Nobody and nothing "forbids" using a tool for something it was not designed for (this was what I meant by "outside its specification"), only judgement and common sense. Since you like RFCs here's a quote from RFC1925: "With sufficient thrust pigs fly just fine. However, this is not necessarily a good idea." With sufficient effort nearly any tool can be brought to do anything - the question is not so much one of being possible, but one of being feasible.

If you use http to transmit files you could use http-get to automate the process. I don't have too much experience with this tool and hence wouldn't recommend it, but from what i know it should do the job.

If you do not like the r-commands (what I can understand, btw., security isn't an issue with them and setting up a kerberos-domain for their k-ized variants is still no fun in 2005) then maybe scp is a solution for you. It is implemented with little effort, works more ore less the same like rcp from outside, with a secure transmission engine inside and the only thing you have to do is to make sure you've got a valid ticket.

Sorry again if i have stepped on anybodies toes with my last point and a special apology to Perderabo whose posts i always enjoy to read.

bakunin