Updated to Indy 10.5207 in case it would help, but didn't. TIdFTP is having trouble connecting to a FileZilla server in UNIX mode. I can connect fine with some FTP client software.
A FTP.Connect generates an exception with no message. On E:Exception ShowMessage(E.Message) shows a blank message.
LastCmdResult.Code = 220
LastCmdResult.Text = the name of the server
Passive and active modes don't work. I've not seen this before. The same code works fine for hundreds of other servers. Any ideas? I can provide IP and some login credentials privately if required.
Thanks.
Ross wrote:
> Does that mean in future if UseHost is True, and a disconnection
> occurs during a HOST command, the component will reattempt a
> connection with UseHost False?
Yes. It was already doing that, but only if the disconnect was detected
after receiving the HOST reply. I have updated it so it can also handle
the disconnect if it happens while sending the HOST command or reading its
reply.
--
Remy Lebeau (TeamB)
> {quote:title=Remy Lebeau (TeamB) wrote:}
I have checked in an update for it.{quote}
Does that mean in future if UseHost is True, and a disconnection occurs during a HOST command, the component will reattempt a connection with UseHost False?
Remy wrote:
> The socket is being closed by the server after TIdFTP has sent a
> HOST command to the server and before the reply has been received.
> Several popular FTP servers are known to close the socket after a
> failed HOST command, but they all typically send a reply before
> disconnecting. Your stack trace suggests the socket is being closed
> first. TIdFTP will have to be updated to account for that.
I have checked in an update for it.
--
Remy Lebeau (TeamB)
Ross wrote:
> exception class : EIdSocketError
> exception message : Socket Error # 10054 Connection reset by peer.
The socket is being closed by the server after TIdFTP has sent a HOST command
to the server and before the reply has been received. Several popular FTP
servers are known to close the socket after a failed HOST command, but they
all typically send a reply before disconnecting. Your stack trace suggests
the socket is being closed first. TIdFTP will have to be updated to account
for that. In the meantinme, you can set the TIdFTP.UseHOST property to false.
--
Remy Lebeau (TeamB)
Hello Ross,
> The ClassName is EIdSocketError.
Then you are not getting an FTP error. The underlying socket is failing,
such as if the socket is being closed as soon as you connect.
> Removing the try..except code doesn't produce an exception in
> the the debugger, perhaps because it executing from a thread.
The debugger shows exceptions regardless of thread context. What is more
likely the case is that you have EIdSocketError in the debugger's list of
exception types to ignore.
--
Remy Lebeau (TeamB)
The ClassName is EIdSocketError.
Removing the try..except code doesn't produce an exception in the the debugger, perhaps because it executing from a thread.
I'll create a new app and run a connect in the main thread and get back to you.
> {quote:title=Ross Levis wrote:}{quote}
> A FTP.Connect generates an exception with no message. On E:Exception ShowMessage(E.Message) shows a blank message.
> LastCmdResult.Code = 220
> LastCmdResult.Text = the name of the server
What is the ClassName of the exception? What does the debugger show as the call stack when the exception is raised? 220 is the server's normal greeting response code. TIdFTP would not raise an exception on that. Something else is failing, but there is not enough information to know what that is.
--
Remy Lebeau (TeamB)
Mega Search
Sign Up 
