> Following a fix:
> The data-socket must effectively be stopped from "accepting" a
> connection once the primary transfer command has failed. If the
> data-socket is simply closed then on client-side an error is raised -
> so my solution is not to call datasocket.accept on the incoming
> conne
> The data-socket must effectively be stopped from "accepting" a
> connection once the primary transfer command has failed.
I found your change made no difference to the issue of the extra
response being generated, since it was triggered when the data socket
was closed, and it was already open
> If you want to reproduce the bug even on a fast connection simply
> enter in File FtpCli
I have reproduced your problem, and clearly the 226 response is bogus
and needs to be removed. I'll look at a fix tomorrow.
20:01:10 FtpS< angusadmin PASV
20:01:10 FtpS> angusadmin 227 Entering Passive
Followup & Fix to my first posting:
If you want to reproduce the bug even on a fast connection simply enter in
File FtpCli
procedure TCustomFtpCli.Next1GetAsync;
...
SetErrorMessage;
FNext := nil;
->Sleep(500);
FDataSocket.Close;
DestroyLocalStream;
...
en
> I found a bug in the FtpCli - FtpSrv combination.
> Steps to reproduce:
>
> 1) (Client) put FtpCli into passive mode
> 2) (Server) assign FtpSrv.FtpServerValidateGet
> 3) (Client) request something from the Server - e.g. with
> FtpClient.Get
> 4) (server) fail the resulting RETR command on the
Hello all,
I found a bug in the FtpCli - FtpSrv combination.
Steps to reproduce:
1) (Client) put FtpCli into passive mode
2) (Server) assign FtpSrv.FtpServerValidateGet
3) (Client) request something from the Server - e.g. with FtpClient.Get
4) (server) fail the resulting RETR command on the serve
