When trying to fix the FXP security problem, a mistake was made, and FXP via FTPS stopped working on Shift + F5.
In addition, FXP sometimes does not work if the session was established with "PROT D", although this is not difficult to fix
CAUSE OF PROBLEM
If server support SSCN command, Shift + F5 incorrectly initializes the second connection: data encryption (PROT P) is always enabled, even if it was disabled in the main session.
DECISION
I suggest you implement a simple, fast and secure algorithm that solves all issues with FXP.
1. Copying a file within a single server (like Shift + F5):
a) first, try using SITE COPY (this is the fastest, and sometimes the only possible way, because FXP may be denied);
b) if it's not supported - use FXP, only ALWAYS with "PROT C" (even if the session was established with "PROT D"), because it's faster, and connecting the server to itself is completely safe, and it's silly to encrypt it;
c) when FXP was fail, then use "Copy via local PC".
2. FXP between two different servers:
a) if user-defined PROT value on both servers is "C" then use "PROT C";
b) if user-defined PROT value of anyone or both server(s) is "P", then try use SSCN; if it's not supported or fail - ask the user to choose between "PROT C" or "copy via local PC" (for security reasons).
c) when FXP was fail, then fallback to "Copy via local PC".
COMMENT
In a good way, you should add the "encrypt data" checkbox to the settings form of the FTPS connection so that the user can easily select the required security level (personally, I usually use "C", and TC uses "P" by default).
Although even now users can specify "PROT C" in the "Send commands" settings, and TC seems to be trying to track this ...
