Stupid question on suspend/resume and command-line FTP

[fouldragon at aol.com]

I use a home-brew backup script that basically loops through some 
directories, grabbing a wad of files, tar/gzip them up, and FTP the 
result to a distant server.  To minimize space footprint, it deletes 
the file after FTP finishes, but it's a very primitive setup-- no error 
catching and retrying.

Normally, the script runs as a cron job, but I wanted to trigger it 
manually today.

So from the command-line, I start the script.

Obviously, I forget to do it in the background, so I end up having to 
control-z and "bg" it.

And that leaves it on my jobs stack, so occasionally, I 'fg' one time 
too many and end up re-suspending-and-backgrounding it.

My concern is:  what impact could this have on the reliability of the 
transfer?

If it stops in the middle of tar/gzip, it will obviously resume, but if 
I stop while it's in the middle of FTPing, what could go wrong?

I could see two possibilities:

1-  If I left it for a while instead of a few panicked seconds, it 
would timeout and drop the connection, ending FTP and moving on to the 
next file.  This would result in a lost file.

2-  It might hiccup, corrupting the file.  Equally bad if not worse.  
I'm assuming that packet checksums and serial numbers (flashing back to 
CSE420 :) ) make this unlikely.

If I check the recipient side and it's uploaded a file of the correct 
size and date, can I assume that it's also uploaded an intact file?  
(the script forces binary mode FTP, so it's unlikely we'd have problems 
with CR-LF conversion)

Since the script takes 8-12 hours to run (and produces, among its 
output, a 5.6G .tar.gz file and several in excess of 1G), I'd prefer to 
not have to either re-run the script or download the results to ensure 
correct function.

________________________________________________________________________
More new features than ever.  Check out the new AOL Mail ! - 
http://webmail.aol.com