The Failed/Retry logic is broken

[lupin]

Client:Flashfxp 2.2 build 994
Server:Proftpd 1.2.9

errors:
================================================== ================
227 Entering Passive Mode (1??,??,??,???,5,193)
RETR rzr-s2.003
Negotiating SSL/TLS session...
550 too many downloading threads under this server , try later.
Transfer Failed!
PASV
227 Entering Passive Mode (1??,??,??,???,5,194)
RETR rzr-s2.005
================================================== =================

When the client got "too many downloading threads under this server " error,it will mark the file as failed,but in fact the real reason is
the server is "busy".
It should be treated as the "busy" status which is something like when connecting to a busy server and retrying under the user's seting.

Because if the server marks the files as "failed" when server is "busy",the user has to "unmark" the files manually very often to let flashfxp transfer again and again!!!!

Flashfxp is great,thanks very much!

[bigstar]

The action is based on the reply number, the standard defined meaning of an 550 is:

550 Requested action not taken.
File unavailable (e.g., file not found, no access).

While the ftp server you describe uses 550 for something non-standard, it must be treated as the standard and expected result.

In my opinion perhaps the ftp server should reply with

450 Requested file action not taken.
File unavailable (e.g., file busy).

If the error reply was 450 I believe FlashFXP would then retry the file.

[lupin]

Can you try to solve this situation?
Maybe let the user define the keyword of response for "retry"
action?

Thanks very much!

[lupin]

I have completely solved this issue by patching 2 bytes
of flashfxp.exe ,version 3.0 build 996.
I have no source codes.

I am not going to post the bytes anywhere,I just want to say
it is very easy to solve,and maybe you developers should
also help ppl out there.
Proftpd is very popular,proftpd+flashfxp is also
very common.