FTP server responses are sometimes undetected in batch

Question

I'm running a batch file in Win2003 to transfer a file via FTP.

The batch file pipes the FTP session results into a FIND to see if there's a 226 success message, and this works well. Unfortunately, from a scheduler I'm hitting the errorlevel condition, even though the file transfers successfully and the 226 message is returned.

FTP -s:go.ftp 2>NUL | Find "226 Transfer OK" > NUL
If ErrorLevel 1 Echo ERROR - FTP transfer failed. >> err.log

The user account is an admin account, so it's not a rights issue. Any ideas?

UPDATE:

The 226 message is not being captured via redirect, thus failing the FIND. In my testing, I redirected the FTP output to a separate file when run from the scheduler. Although the FTP commands are running successfully, none of the server responses are appearing.

Here is my FTP script:

open ftpsite
username
password
dir
quit

Here is the output ( FTP -s:go.ftp >ftp.log 2>ftp.err ).

User (ftpsite:(none)): open ftpsite
04-01-12  02:35PM       <DIR>          DIR1

04-01-12  02:35PM       <DIR>          DIR2

04-01-12  02:35PM       <DIR>          DIR3

04-01-12  02:35PM       <DIR>          DIR4



dir 
quit

Additionally, nothing appears in the error stream ( 2>ftp.err ). At least I know now why my FIND's errorlevel isn't being triggered, but why aren't the FTP server responses being captured? I'm not using the -v switch or toggling verbose.

Answer 1

Does the path for the scheduler include the directories of FTP and FIND?

Can you save the output of FTP to a temporary file, and pipe that to FIND for test purposes? That way you can examine FTP's output after the fact to see what might have happened.

How about leaving out the redirects (or directing the output to an error log file) so you can review the batch file's output for possible error messages?

Answer 2

I ran across this researching a single missing 226 code in a series of otherwise successful transfers. My ftp command is being invoked from vbscript, but is otherwise similar to yours:

ftp -i -n -s:"\path\to\cmdfile.txt" [ftpserver] > "\path\to\stdout.log" 2> "\path\to\stderr.log"

Because of the -n switch and anonymous login, my command file differs slightly:

USER anonymous
cd [UploadDirectory]
binary
put [file]
quit

As you noted, the STDERR stream always seems to be empty - even when a connection is unsuccessful. In all my testing, I've never seen STDERR contain any information. STDOUT, however, contains a full log of the transactions:

220 Unauthorized access to this server is prohibited. All actions are logged.
USER anonymous
230-Anonmyous Access
230 Login successful.
cd [UploadDirectory]
250 Directory successfully changed.
binary
200 Switching to Binary mode.
put "[file]"
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
1058.3090.82quit
221 Goodbye.

Instead of piping the command to FIND as in your example, I'm parsing the STDOUT file and 99% of the time a match is made on "226 Transfer complete."; 1% of the time I only see

150 Ok to send data
quit

In the cases where the 226 is missing, the file is successfully transferred (??) and appears intact. All of this to say that while not as elegant as piping the output to FIND, parsing the STDOUT file should give you the desired results.

A few other items I can think of:

1. Most scheduler / cron issues are caused by paths and permissions. MS Scheduler includes a "Start In (folder)" option - have you tried setting that to the batch file directory? Also, the user account for which you're running the scheduled job should probably be given explicit (not inherited) permissions on all files and folders utilized by the batch. If the batch consistently works from the command line but fails on the scheduler, there might be more to a permissions issue than simply adding the scheduler user account to the admin group.
2. What do your server ftp logs show? My ftp server is vsftpd (Linux) and my server logs essentially mimic the STDOUT stream as captured by the redirect (with a some additional information). This might tell you whether or not the transfer success codes are even being transmitted from your ftp server.
3. Probably not the cause, but consider using the /I switch with FIND to make it case-insensitive
4. Have you tried messing with the redirection command? Something akin to: ftp ... 2>&1 | find ...