We have a legacy system that is using the built in Windows commandline ftp client to upload files to an ftp server. It does this using the -s switch, with an ftp file something like the following:
debug
open myftpsite.com 21
<username>
<password>
cd remote_folder
ascii
lcd "c:\myfolder"
prompt
put export.txt export.tx
rename export.tx export.txt
quit
This works 99% of the time, but the other 1% of the time it doesn't. When it runs successfully the resulting logfile contains response messages from the server like "250 OK" after each of the commands above. The problem is sometimes it seems to fail to connect then we get NO messages in the logfile (from the server or ftp client) at all. The ftp client also still seems to return a process exit code of 0.
Does anybody have any suggestions for:
Getting better logging back from the built in Windows commandline ftp client?
AND\OR
Forcing it to return a Process Exit Code other than 0 to indicate something has gone wrong?
Best Answer
Your best bet is to run Wireshark or tcpdump on either the client or the server when you are using FTP to try and discover what's actually going wrong. Something like the example below should be sufficient.
Try using either just Active or Passive mode to see if it's a firewall issue. Try a better FTP client such as WinSCP, or Filezilla. And finally, examine whether you need to use FTP at all. There are far better and more secure options such as SCP/SFTP.