Unexpected behavior with FTR's

The FTR feature seems to be malfunctioning and not correctly resuming files during local download. I have been experiencing this for a very long time but had little time to investigate or try newest version to confirm it still happens.

*Queue a folder and begin transferring (downloading).
*Interrupt the transfer, both hard d/c and a soft abort produce the same result.
*Start the transfer again and observe unexpected behavior.

[13:05:12] (soft abort)
[13:05:12] [L] 426 Data connection: Broken pipe.
[13:05:13] [L] Transfer Failed: bk-mysql-20141006.tar.gz
[13:05:13] Transferred 0 Files (0 bytes) in 9 seconds (0.0 KB/s)
[13:05:13] Aborted by user
[13:05:54] [L] PASV
[13:05:54] [L] 227 Entering Passive Mode (...)
[13:05:54] [L] Opening data connection IP: ... PORT: ...
[13:05:55] [L] RETR bk-www-20141006.tar.gz
[13:05:55] [L] 150 Opening BINARY mode data connection for bk-www-20141006.tar.gz (192884001 bytes) using SSL/TLS.
[13:05:55] [L] TLSv1 negotiation successful...
[13:05:55] [L] TLSv1 encrypted session using cipher ECDHE-ECDSA-RC4-SHA (128 bits)

As you can see from the log when manually starting the queue again the previously transferring file is skipped. Some tinkering with my FTR options narrowed this down to the previous file (bk-mysql-20141006.tar.gz) triggering the 'On Transfer Error' setting which was set to 'Skip'. Confirmed this by testing with this set to Resume (it resumed the file) and Ask (it prompted).

FlashFXP did not always do this but it was so long ago that a change made it start acting this way that I can not recall. However this behavior is not intuitive and in my opinion a file transfer failure of this nature (a site disconnection or even user abort) should not trigger the On Transfer Error rule without first rechecking the file against the configured FTRs.

As a side note, prior to v5 you could easily see what the FTRs were doing by the messages in status and error/transfer windows but those messages seem to be gone. If intentional can they be made optional rather than just removed?

FTRs: http://prntscr.com/4u3bly

EDIT: on further investigation it is only those log messages related to this behavior that no longer show up, in v4 it would show 'Skip [File Exists]' (or unknown). Even though those messages don't really reflect what is actually happening they were helpful in knowing something wasn't right.

The file transfer rules haven't changed for quite some time, The last change to the logic was probably v4.0

Rules: If the file already exists on the server then the user-defined rules are applied.

On transfer error: This rule is applied if the file transfer times out or is interrupted. Whether its user or server related.

If no rule matches then: This is applied when none of the user-defined Rules match.

If a file is skipped due to a rule there's still the status indicator text. If the reason for skipping is to to the OTE (on transfer error) action set to skip then it may show as unknown as the reason. I will change this to OTE in the next update.

I spent some time evaluating the rule logic and behavior (everything appears to work as intended); as well as reviewing the changelog from past releases and I discovered that in some v4.x releases the OTE action did not always trigger due to one thing or another and instead the user-defined rules were mistakenly applied.

After spending another hour or so testing the functionality I can confirm it does work as intended, however I can see how the behavior might be appear as unexpected to some while not to others.

Say you're downloading dozens of 100+GB files and want to overwrite any already existing files and resume files on any type of transfer failure.

You'd add a user-defined rule to overwrite on download.

Set the OTE action to resume.

Now if anything (user or server) results in a transfer error during the session FlashFXP will resume the file to complete it.

The OTE state doesn't take effect until after the file starts transferring, so if there's a failure establishing the transfer then this rule is not applied. (according to my notes some builds of v4.x didn't handle this correctly)

One thing I realized during my in-depth tests was that there should probably be one more OTE action and that is something to the effect of "Use Rules", for customers who don't want to use a specific rule on transfer error and would rather apply their user-defined rules to handle all situations. I can see a few rare cases where this might be useful.

Thank you for looking into this and breaking it down.

It has likely been years since this first started bothering me and it was mostly due to unexpected server connection drops. But I see that this is exactly the situation that the OTE setting is for.

I don't recall exactly why I needed OTE set to skip in the past ;s