FlashFXP 4.1 RC 3 build 1640

[bigstar]

FlashFXP 4.1 Build 1640 (RC 3)

1. Fixed > Local Browser > File List > Dragging a file within the file list and dropping on another file resulted in the file being moved to the parent folder.
2. Fixed > Local Browser > File List > Drag / Drop displayed the no drop mouse cursor but still attempted to perform the drop operation.
3. Fixed > Server > FTP > Active mode (PORT) > Port mode operations would often fail with a timeout. This was caused by a defect in the listening routine.
4. Fixed > Server > Secure FTP > The SSL/TLS handshake could sometimes fail due to a defect in the handshake routine.
5. Fixed > File Transfer Status-bar > Remaining, Elapsed, Queue > The Text formatting routine failed to separate the minutes from the seconds.
6. Fixed > File Transfers > The "Filename case conversion" function was returning an invalid result causing file transfers to fail.
7. Added > The Key Manager (for managing X.509 certificates / RSA Keys / DSA keys) is now directly accessible via the main menu under Sites.

Additional Information:
I changed the default floating-point unit in this release, All releases for the last 10 years disabled floating point exception errors and this was not the intended behavior. It's possible that this change might introduce some unexpected crashes, this will allow us to address any FPU issues, rather than keeping them hidden.

Known bugs:
I would like to think all known issues have been resolved. If I'm mistake or you find a bug please let me know, I will be forever in your debt

[Yil]

Expand folder(s) while offline fixed, though I don't remember seeing a change notice to that effect.

I still have an issue with the list/stat timeout. I don't understand why it needs to be changed from v3.x and v4.0. I know ioFTPD has some speed issues the first time it opens a directory with a 1000+ subdirs, as does raidenFTPD, because we have to examine the permission info in each subdir before we can return the directory listing and this change is making that much more obvious and very annoying. This is also sometimes true even with drFTPD or glFTPD when nobody has used the server in a bit and it has to swap in a lot of memory and the disk is busy.

Here's the scenario I see. User has say a 1 login limit, they request a dir listing on a large fan-out dir that's going to take a minute or maybe even almost 2 minutes to open the first time. 4.1 will drop the control connection after 30 seconds. If they notice this and attempt to reconnect it's likely they'll be denied login because the server hasn't figured out the other login can be closed out because it's still busy processing the directory listing. When that does timeout they can relogin, but it's very annoying.

Some rough comparisons...

v4 timeout from LIST to first byte of directory listing is 2 minutes if plaintext, and 3 minutes if SSL/TLS, but v4.1 is 30 seconds. v4 timeout between data reception after the first packet for things like LIST -alR is 1 minute, v4.1 is 30 seconds. Hmm, the v4.0 test had the default 60 sec restart data policy (I just installed the 4.0 usb release to test) so it's possible those timeouts could be raised but I should have to double check that as I know it doesn't work that way in 4.1. v4.1 had a 600(!) second timeout for local testing, but it's ignored because it's a list...

I'm trying to find ways to prevent timeouts from happening in a future ioFTPD release and sending something every 30 seconds against a 2 minute (or 1 min) timeout seemed possible, but having to do so every 10 or 15 seconds against a 30 sec timeout will be much harder to do.

I think you fixed it so SITE commands can take the old 2 minute timeout which is great because I've finally gotten scripters to output something every 30 seconds

I can't think of any reason why shorter timeouts are a good thing. If a user is that impatient let them hit the disconnect button and then the reconnect button themselves, but with shorter timeouts people who DON'T want this behavior are stuck with it. It's doubly annoying if they have login limits, and insanely annoying (though their own fault) if they have a short reconnect timeout and manage to get themselves auto-banned from the server for a while because of connecting too often.

[bigstar]

The problem appears to be time-out consistency issue and I've come up with a new way to address this issue, rather than trying to put a band-aid on the problem I decided to completely redo the way time-outs are tracked.

I am having a difficult time finding suitable servers for testing these changes to insure that everything works as intended. Unfortunately none of my test servers display any type of delay when entering a folder for the first time.

The timeout is intended to be adaptive to the action being performed, most commands are instant, these commands have a 20 second timeout, any command sent via a raw command has a 10min timeout regardless of the command.

A special command such as STAT -L, is supposed to have a 2 minute timeout, but due to an issue with managing the timeouts it is using the 20 second timeout. ARGH.

As soon as the server sends the first line of the status reply the timeout is supposed to be reset, the timeout doesn't define how long the operation can take, but rather how long FlashFXP will wait for the server to actually send the reply, and how long FlashFXP will wait between each segment of data.

Whether or not it actually works as intended is another story, as I need to come up with a better way of testing this.

[Yil]

Hmm, I can definitely see how testing would be an issue... You could always do what I do, fire up the latest ioFTPD under the debugger (it only takes 10 min to setup the first time) and drop in some breakpoints ioFTPD releases include the .pdb files so the entire source should be available that way, but you can grab the source release for the individual files as well though building it from scratch isn't something I'd recommend since it's a pain to setup TCL/OpenSSL...

If you do go that route check out SocketAPI.c and the TransmitPackages_* routines, _ReadFile is for sending files, and _SendListBuffer is for sending directory listings and are both called after connections are made and SSL/TLS is finished so it's a good spot to drop a breakpoint. Most FTP commands are in FtpBaseCommands.c if you want to break on something else, and of course I'd be more than happy to point out whatever you're looking for.

For the record ordinary commands like CWD can take a while as well so probably needs a longer timeout if your doing something adaptive. Sometimes reading the directory takes a while if it isn't in cache (much like the directory listing would) and other times I've seen external USB drives take a bit of time to spinup and access data. Not sure why but sometimes that takes 10 seconds on top of whatever the FTP would normally add and that would apply to almost anything like SIZE, MDTM, etc. I'm guessing 30 seconds is usually good, but as I was saying before I don't really see the downside to 2 minutes because the alternative is dropping the control connection and you can always get that behavior doing it manually.

[Yil]

The bug with multiple selected files being queued not greying their icons until moused over still looks like it exists.

[bigstar]

I've refined the timeout feature for the next build please let me know if its any better.