No, it cannot be ignored. Unfortunately, this isn't something the client can reliably do, and the root cause lies in the design of the FTP protocol itself.
During a transfer, the FTP control connection is shared between the transfer command (STOR/RETR) and any other commands. The protocol doesn't expect new commands to be sent while a transfer is in progress, so the behavior is server-specific:
- Some servers silently accept NOOP and reply 200 OK.
- Some servers reject it with a 4xx or 5xx error, in a wording of their own choosing.
- Some servers delay the reply until the transfer completes.
FTP replies carry no command identifier, so the client can only match them to commands by their order. Whenever the server replies with an error, the client has to decide whether it is the answer to the NOOP, or the final result of the transfer itself (for example 451 Local error in processing, 426 Connection closed; transfer aborted, 552 Disk quota exceeded). The only way to tell them apart is by the text of the message, which is not standardized, and often not even by the reply code, since many servers use the same code (e.g. 451) for both situations.
If we ignored all errors received after a KeepAlive (NOOP), we would also swallow real transfer failures. The upload could then be reported as successful even though the file on the server is incomplete or missing. That is silent data loss, which is much worse than a spurious exception, so we deliberately ignore only the messages we know to be harmless.
Possible solutions:
1. Disable `KeepAliveDuringTransfer`. This is the safest choice and works with every server. It is only needed if your firewall or the server drops idle control connections during very long transfers.
2. Keep it enabled only for servers where it is known to work, and disable it for Wing FTP Server.
3. We can send you preview build with support for this message.
