Command line FTP hangs

Okay, I'm officially stumped.
Connecting to FTP via the command line, whether directly or through a script, results in:

Code:

Connected to ftp.MyDomain.com.
220-Microsoft FTP Service
220 Winhost.com FTP
ftp> user MyFTPUserName
331 Password required for MyFTPUserName.

230-Welcome
230 User logged in.
ftp> ascii
200 Type set to A.
ftp> cd \MyDir\
250 CWD command successful.
ftp> prompt
Interactive mode Off .
ftp> mput File01.txt File02.txt File03.txt
200 PORT command successful.
150 Opening ASCII mode data connection.

and then it just hangs, with the cursor blinking at me vacantly. No files are uploaded, and I have to Ctrl-Break outta there.
Any assistance greatly appreciated!

Phillip

 

A bit more information:

Both mput and put definitely hang up as above and do not execute, and the same with get. Rename works with no problem. Curiouser and curiouser...
Anybody?

 

Thanks for your reply, C Man. I use FileZilla for manual FTP transfers. I'm trying to use the command line FTP to automate some transfers with a script. With or without a script, however, mput, put, mget and get just hang at the line indicated above. This worked very well with my previous host, but it hasn't since I moved to Winhost. Any ideas?

 

To be clear, if you use FileZilla and manually upload the files, you have no problem. But if you try to automate some transfers and used the FTP script, it fails? When you stated "automate some transfers with a script" just exactly what are you running? Are you running some kind of script on your computer and setting it up on your Windows Scheduled Task Manager?

 

Hi Ray, thanks for replying. Sorry if I wasn't clear, but you have grasped the situation. Manual transfers with FileZilla are fine. It's the command line FTP that fails, and it fails whether I'm entering commands one by one via the keyboard, or using a script. The example I gave in my first post was from typing in commands singularly; I was using that method to try to understand why my script doesn't work.
Here's what used to work for me: I used a line in a .bat file to pass file names to a .cmd file that wrote the script and called the command line FTP (see below).

.bat file:

Code:

start "" /wait Upload.cmd file01_.txt file02_.txt file03_.txt
exit

Upload.cmd:

Code:

@echo off
echo user MyUserName> ftpcmd.dat
echo MyPassword>> ftpcmd.dat
echo cd \MyWebDir\
echo ASCII>> ftpcmd.dat
echo prompt>> ftpcmd.dat
echo quote pasv
echo mput %1 %2 %3>> ftpcmd.dat
echo rename file01_.txt file01.txt>> ftpcmd.dat
echo rename file02_.txt file02.txt>> ftpcmd.dat
echo rename file03_.txt file03.txt>> ftpcmd.dat
echo quit>> ftpcmd.dat
ftp -n -s:ftpcmd.dat ftp.MyDomain.com
del ftpcmd.dat
exit

Although, like I said, since manually typing into the command prompt hangs, the script isn't the problem. I've tried it both with and without "echo quote pasv" with identical results. It seems to me that for some reason mput, put, mget and get commands are either not being received or processed by the server.
I appreciate your help.

 

Hi Fred, and thanks for responding. Of course, that's a good idea, and one which I tried previously. I tried it again just now, and the result was still no file uploaded. Here are the records:

Using FileZilla:

Code:

Status:   Resolving address of ftp.MyDomain.com
Status:   Connecting to xxx.xxx.xxx.xxx:xx...
Status:   Connection established, waiting for welcome message...
Response:   220-Microsoft FTP Service
Response:   220 Winhost.com FTP
Command:   USER MyUserName
Response:   331 Password required for MyUserName.
Command:   PASS ********
Response:   230-Welcome
Response:   230 User logged in.
Command:   SYST
Response:   215 Windows_NT
Command:   FEAT
Response:   211-Extended features supported:
Response:    LANG EN*
Response:    UTF8
Response:    AUTH TLS;TLS-C;SSL;TLS-P;
Response:    PBSZ
Response:    PROT C;P;
Response:    CCC
Response:    HOST
Response:    SIZE
Response:    MDTM
Response:    REST STREAM
Response:   211 END
Command:   OPTS UTF8 ON
Response:   200 OPTS UTF8 command successful - UTF8 encoding now ON.
Status:   Connected
Status:   Retrieving directory listing...
Command:   CWD /MyDir
Response:   250 CWD command successful.
Command:   PWD
Response:   257 "/MyDir" is current directory.
Command:   TYPE I
Response:   200 Type set to I.
Command:   PASV
Response:   227 Entering Passive Mode (199,233,253,128,19,213).
Command:   LIST
Response:   150 Opening BINARY mode data connection.
Response:   226 Transfer complete.
Status:   Calculating timezone offset of server...
Command:   MDTM -ARC-.jpg
Response:   213 20140428014604
Status:   Timezone offsets: Server: -25200 seconds. Local: 36000 seconds. Difference: 61200 seconds.
Status:   Directory listing successful

Command:   TYPE A
Response:   200 Type set to A.
Command:   PASV
Response:   227 Entering Passive Mode (199,233,253,128,19,229).
Command:   STOR test.txt
Response:   150 Opening ASCII mode data connection.
Response:   226 Transfer complete.
Status:   File transfer successful, transferred 27 bytes in 1 second

Command:   RNFR test.txt
Response:   350 Requested file action pending further information.
Command:   RNTO test_.txt
Response:   250 RNTO command successful.

Manually typing into command prompt:

Code:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\your>cd "C:\My Local Dir\Subdir"

C:\My Local Dir\Subdir>ftp
ftp> open ftp.MyDomain.com
Connected to ftp.MyDomain.com.
220-Microsoft FTP Service
220 Winhost.com FTP
User (ftp.MyDomain.com:(none)): MyUserName
331 Password required for MyUserName.
Password:
230-Welcome
230 User logged in.
ftp> quote opts utf8 on
200 OPTS UTF8 command successful - UTF8 encoding now ON.
ftp> quote cwd /MyDir
250 cwd command successful.
ftp> quote pwd
257 "/MyDir" is current directory.
ftp> quote type a
200 Type set to A.
ftp> quote pasv
227 Entering Passive Mode (199,233,253,128,19,224).
ftp> quote stor test.txt
150 Opening ASCII mode data connection.
ftp>

And there it stops, with the cursor blinking at me more insolently with every attempt! No file is uploaded.

If I switch put test.txt for quote stor test.txt it hangs as previously on 150 Opening ASCII mode data connection., until after many minutes I Ctrl-Break:

Code:

ftp> put test.txt
200 PORT command successful.
150 Opening ASCII mode data connection.
Control-Break
550 An unexpected network error occurred.

So that's where I'm at with it -- nowhere!

 

Thanks, Fred. I'll try that and let you know how it works.

 

Solved! Thanks for the tip, Fred. WinSCP was the answer. There was a bit of a learning curve involved, but I guess that's to be expected. For anyone who might benefit, here is the solution.

A .bat file which includes these lines is put into Windows Task Scheduler:

Code:

@echo off
cd "C:\My Local Dir\Subdir"
start "" /wait Upload.bat
exit

C:\My Local Dir\Subdir\Upload.bat:

Code:

@ echo off
echo option batch abort > ftpcmd.dat
echo option confirm off >> ftpcmd.dat
echo open ftp://MyUserName:[email protected] -passive=on >> ftpcmd.dat
echo cd /MyWebDir >> ftpcmd.dat
echo put -transfer=ascii file01.tx_ file02.tx_ file03.tx_ ./ >> ftpcmd.dat
echo mv file01.tx_ file02.tx_ file03.tx_ file0*.??t >> ftpcmd.dat
echo exit >> ftpcmd.dat
"C:\Program Files\WinSCP\WinSCP.com" /script=ftpcmd.dat /log="C:\My Local Dir\Subdir\winscp.log"
del ftpcmd.dat
exit

Thanks again.

 

Persistence pays off!

Glad you worked it out.

 

You can also try using passive mode buy using "ftp -p" .

 

Using PASV does not solve the problem for me, leading me to believe there is an underlying Windows process blocking the port. Worse than that, I am only using CmdLine FTP to diagnose why my MFC application suddenly started failing to upload files. It's on an XP dedicated to this task only. I have turned off the Windows Firewall. The same process works fine on other machines on the same network. Any ideas?

 

Thanks Fred, but this really is a problem with a specific Windows PC, not your FTP server. The FTP apps on this PC worked great for many months until this problem arose. And they work fine on other PCs, so the problem would be something that arose on that specific machine. Maybe the Windows Firewall is not quite turning off, or something else is blocking the data channel access. I'm just not sure how to diagnose it.