FlashFXP 4.1 build 1548 stable

[ecksteinn]

I experience problems since a very few latest releases in combination with actual raidenftpd and implicit and explicit SSL/TLS and binary file uploads

FFXP hangs and freezes

[mats_k]

Two issues
1. Is it possible to change the order of how to present the data in the program-header?
Now the presentation seem to be (I have attached a picture)
speed queue % filename

2. When the flashfxp is not maximized I have a very irritaded flickering behaviour of the presentation.
If flashfxp is maximized then the flickering is not available.

FYI:
Win7 x64 sp1
flashfxp 1648

Attached picture for issue 1 and issue 2

[bigstar]

I experience problems since a very few latest releases in combination with actual raidenftpd and implicit and explicit SSL/TLS and binary file uploads

FFXP hangs and freezes

The only thing I can think of that may of caused this is when we updated the OpenSSL dlls to the latest release. We haven't touched the FTP SSL/TLS code for many builds now, that code was finalized awhile back.

I used to have a license key for raidenftpd but it appears I've misplaced it, I've contacted the raiden team but I'm not sure how long it might take before I have a replacement key. As soon as I am able to test raidenftpd I will do so.

If you could provide me with a test account on a raidenftpd server that would be a huge help, if this is possible please send me a private message.

[bigstar]

Two issues
1. Is it possible to change the order of how to present the data in the program-header?
Now the presentation seem to be (I have attached a picture)
speed queue % filename

2. When the flashfxp is not maximized I have a very irritaded flickering behaviour of the presentation.
If flashfxp is maximized then the flickering is not available.

FYI:
Win7 x64 sp1
flashfxp 1648

Attached picture for issue 1 and issue 2

Yes you can customize the taskbar caption during file transfers, this setting can be configured via the Preferences dialog > Transfer > Taskbar Caption

Do you have visual themes turned off for FlashFXP in Windows 7? Based on your screenshot it appears you do. This can create unnecessary flickering, the only solution would be to turn visual themes back on for FlashFXP.

Enabling any unnecessary compatibility settings for FlashFXP under Windows Vista or Windows 7 can cause unexpected and unpredictable results.

If the flicker is limited to a specific part of the FlashFXP window can you please explain where the flicker occurs and what you're doing at the time.

[mats_k]

Yes you can customize the taskbar caption during file transfers, this setting can be configured via the Preferences dialog > Transfer > Taskbar Caption

Do you have visual themes turned off for FlashFXP in Windows 7? Based on your screenshot it appears you do. This can create unnecessary flickering, the only solution would be to turn visual themes back on for FlashFXP.

Enabling any unnecessary compatibility settings for FlashFXP under Windows Vista or Windows 7 can cause unexpected and unpredictable results.

If the flicker is limited to a specific part of the FlashFXP window can you please explain where the flicker occurs and what you're doing at the time.

Ok thanks for the quick reply.
I just downloaded the 4.1 stable version and upgraded from the earlier stable 4.0.
Then the Interface/Toolbar for both the
- Main buttons and
- Navigation Buttons
changed from old classic to new tango.
I just changed back to the classic style .
Even if I try to import my old 4.0 settings I get tango for the "Main buttons and Navigation buttons"

After some other tweaks the flickering has disappeared.
And I am back to the way I had it before the upgrade....
:)

[bigstar]

Then the Interface/Toolbar for both the
- Main buttons and
- Navigation Buttons
That is correct, in 4.1 we promoted the tango theme as default, since this has become default, when importing or upgrading from 4.0 it will always use tango, the only way to override/change this is to manually select the classic buttons.

[bigstar]

I experience problems since a very few latest releases in combination with actual raidenftpd and implicit and explicit SSL/TLS and binary file uploads

FFXP hangs and freezes

I finally had a chance to test with RaidenFTPD v2.4 build 3903 (2011/9/19) and I was not able to reproduce the issue. What version of Windows are you using?

[TuSSy]

Hello,
i am having issues transfering files from SSL or not FTP servers.
This started after build 1625 (Which works if installed)
if i install build 1640 or any version after that one i can not transfer (UL or DL) any files.

When the transfer is started, a few ko do come through and thet ffxp just throws that broken pipe error and tries to resume.

if i reinstall the build 1625 then all is back to normal.


Log from a SSL site:
[L] PASV
[L] 227 Entering Passive Mode (xxx,xxx,xxx,xxx,195,184)
[L] Opening data connection IP: xxx,xxx,xxx,xxx PORT: 50104
[L] RETR e-aca.r00
[L] Connected. Negotiating TLSv1 session
[L] 150 Opening BINARY mode data connection for e-aca.r00 (50000000 bytes) using SSL/TLS.
[L] TLSv1 negotiation successful...
[L] TLSv1 encrypted session using cipher DHE-DSS-AES256-SHA (256 bits)
Transfer Timed Out
[L] 426 Data connection: Broken pipe.
[L] Transfer Failed!

log from a local FTP server running on the same machine as FFxp:
[L] PASV
[L] 227 Entering Passive Mode (192,168,1,2,5,165)
[L] Opening data connection IP: 192.168.1.2 PORT: 1445
[L] RETR abs-ttkh.bin
[L] 150-Let's go for it...
[L] 150 Sending /abs-ttkh.bin (777016128 bytes). Mode STREAM Type BINARY
Transfer Timed Out
[L] 426 Connection closed (exception : An established connection was aborted by the software in your host machine. )
[L] Transfer Failed!

[bigstar]

Hello,
i am having issues transfering files from SSL or not FTP servers.
This started after build 1625 (Which works if installed)
if i install build 1640 or any version after that one i can not transfer (UL or DL) any files.

When the transfer is started, a few ko do come through and thet ffxp just throws that broken pipe error and tries to resume.

if i reinstall the build 1625 then all is back to normal.


Log from a SSL site:
[L] PASV
[L] 227 Entering Passive Mode (xxx,xxx,xxx,xxx,195,184)
[L] Opening data connection IP: xxx,xxx,xxx,xxx PORT: 50104
[L] RETR e-aca.r00
[L] Connected. Negotiating TLSv1 session
[L] 150 Opening BINARY mode data connection for e-aca.r00 (50000000 bytes) using SSL/TLS.
[L] TLSv1 negotiation successful...
[L] TLSv1 encrypted session using cipher DHE-DSS-AES256-SHA (256 bits)
Transfer Timed Out
[L] 426 Data connection: Broken pipe.
[L] Transfer Failed!

log from a local FTP server running on the same machine as FFxp:
[L] PASV
[L] 227 Entering Passive Mode (192,168,1,2,5,165)
[L] Opening data connection IP: 192.168.1.2 PORT: 1445
[L] RETR abs-ttkh.bin
[L] 150-Let's go for it...
[L] 150 Sending /abs-ttkh.bin (777016128 bytes). Mode STREAM Type BINARY
Transfer Timed Out
[L] 426 Connection closed (exception : An established connection was aborted by the software in your host machine. )
[L] Transfer Failed!

Can you please give me the values for the following settings in the Preference dialog

In the section Transfer > Options Stalled transfers

[ ] Restart transfer if no data is transferred for [ ] seconds

In the section Connection

TCP/IP Buffer Size

Send [ ]

Receive [ ]

[spudgun]

Couple of things that I've noticed in 4.1 (they may have also been present in previous builds)

1) I get loads of MLST errors on every upload (fxp in)

[L] 200 Command okay
[L] MLST [filename removed]
[L] 250- Begin
[L] type=file;size=5778968;modify=20110921223647.696;u nix.owner=[removed];unix.group=[removed];x.slaves=[removed];x.xfertime=-[filename removed]
[L] 250 End.
[R] TYPE I
[R] 200 Command okay
[R] MLST [filename removed]
[R] 550 Requested action not taken. File unavailable (e.g., file not found, no access)

2) Live update appears in the status window every day even though i've got it not to check for any kind of update

Any idea of what I can do to deal with these 2 issues?

Many thanks

Spud

[bigstar]

1. This is the normal behavior, FlashFXP will use the SIZE or MLST command to determine if the file exists before uploading. You can disable this feature by unchecking the option "Request file size/date prior to transfer" in the File Transfer Rules dialog, however by doing this you will reduce accuracy of the file transfer rules and increase the likelihood of the wrong rule being used.

2. At the moment the update check cannot be turned off, we will be allowing users to disable it in a future release.

[spudgun]

Thank you very much for your helpful reply

[jharmen]

Since i updated to the newest version 4.1.0 1648 my download speeds are way slower then when i use 4.0.0 1548. I can't find the reason why, anyone got a idea ?

[bigstar]

Since i updated to the newest version 4.1.0 1648 my download speeds are way slower then when i use 4.0.0 1548. I can't find the reason why, anyone got a idea ?

Can you please answer the following questions.

Windows version:

Software firewall brand/version:

System CPU and memory:

Type of internet connection (dsl/cable/etc) as well as the speed:

What speed do you see with 4.0 and now with 4.1:

What is the "connection type" for the site profile:

When transferring files with the FTP protocol there is a feature called MODE Z that performs stream compression on the file transfer, is it enabled? This can be determined by reviewing the server session status window.

Also the transfer speed reported in 4.0 was not very accurate, the method used to calculate the speed was changed in 4.1 which may also skew the result, its best to measure the speed externally if possible when comparing 4.0 to 4.1.

[TuSSy]

Can you please give me the values for the following settings in the Preference dialog

In the section Transfer > Options Stalled transfers

[not enabled ] Restart transfer if no data is transferred for [60] seconds

In the section Connection

TCP/IP Buffer Size

Send []

Receive []

Here are my settings
In the section Transfer > Options Stalled transfers

[Disabled] Restart transfer if no data is transferred for [60] seconds

In the section Connection

TCP/IP Buffer Size

Send [1024]

Receive [1024]

[jharmen]

Since i updated to the newest version 4.1.0 1648 my download speeds are way slower then when i use 4.0.0 1548. I can't find the reason why, anyone got a idea ?

It is my fault, i bought a Linksys SE2500 today, seems it cant handle the download. Still weird because from LAN it peeks at 80mb/s from WAN max 5/6 mb/s instead of 15 :@

[bigstar]

Here are my settings
In the section Transfer > Options Stalled transfers

[Disabled] Restart transfer if no data is transferred for [60] seconds

In the section Connection

TCP/IP Buffer Size

Send [1024]

Receive [1024]

Since the stall detection is disabled I highly suspect the large tcp/ip buffer to be the issue, I would recommend trying (default) and then see if things improve.

[theo]

small issue:
after a folder delete in the remote window
double clicking the "Parent Directory" link in the remote window has no effect (you have to select something else before).
is this an expected behavior ?

[TuSSy]

Since the stall detection is disabled I highly suspect the large tcp/ip buffer to be the issue, I would recommend trying (default) and then see if things improve.

I set the TCPIP buffer back to "Default" but that does not change anything.
Then i enabled the stall detection and things were back to normal.

It really seem that as soon i disable the stall detection i have download timeout problems.

I also tried different combinations for the TCPIP Buffers with no success while having the stall detection disabled.

Between every change of settings i restarted FFxp to be sure to apply the new configuration

[bigstar]

I set the TCPIP buffer back to "Default" but that does not change anything.
Then i enabled the stall detection and things were back to normal.

It really seem that as soon i disable the stall detection i have download timeout problems.

I also tried different combinations for the TCPIP Buffers with no success while having the stall detection disabled.

Between every change of settings i restarted FFxp to be sure to apply the new configuration

There appears to be a problem with the stall detection feature in FlashFXP, I'm afraid that this issue was missed. In order to properly use FlashFXP you will need to enable the stall detection. We will be releasing a fix in the next few days to address this issue.

[bigstar]

small issue:
after a folder delete in the remote window
double clicking the "Parent Directory" link in the remote window has no effect (you have to select something else before).
is this an expected behavior ?

Thank you for bringing this to my attention, I have confirmed the issue and we will be including a fix in the next release.

[bigstar]

I have released 4.1 build 1650 via LiveUpdate (you need to check for beta & stable updates to see it)

In the next day or two I will make the update available for everyone. I want to make sure that all the issues are fixed and no new bugs were introduced.

Below is a changelog

1. Fixed an issue where certain raw command groups contained invalid keyboard shortcuts that would be bound to standard A-Z characters without a (alt, ctrl, shift) modifier, in most cases binding to the "e" key, this prevented the "e" character from being entered.
2. Fixed an issue with plain text FTP downloads being incomplete (missing the last few bytes) under heavy disk i/o.
3. Updated the installer script engine to resolve an issue with FlashFXP failing to install on large hard drives (the previous fix was a crude patch), this is an official update from the developer.
4. Fixed 'compare folder' and 'transfer mode' tool-bar button defect, after clicking the drop-down arrow the button arrow disappeared.
5. Fixed defect in the behavior of the "Stalled transfers > Restart transfer if no data transferred" option, when the option was unchecked the feature did not disable as intended and the stall detection timeout was to 0 seconds triggering a timeout.
6. Added status-bar status icon indicator to reflect when FTP MODE Z or SFTP compression is enabled.
7. Fixed an issue where the "parent folder" item in the server file list was unclickable after performing a remote folder delete.
8. Fixed an issue where local browser would revert back to the default local path after a file transfer if the connection is lost or if you're not connected to the server when the transfer is executed.
9. Fixed an issue when importing sites from total commander, the password field wasn't decrypted correctly.
10. Changed the way the navigation tree monitors for folder changes, in previous builds FlashFXP monitored all drives, now only the drive of the selected folder is monitored for changes. This change was needed to resolve an issue that prevented the user from removing removable hard drives while FlashFXP was running.

[Yil]

Hmm... Can you double check this FXP behavior.

With 2 people sending to a directory I'm watching FXP request the SIZE of the file that got uploaded by another user (after the last directory listing), get a valid size response of the full file size, and then watching FXP try to overwrite the file. No resume, just a plain STOR. This fails because the file is already there, but I don't think I remember flash doing that before.

Both sites are using the global rules, request file/size prior is checked, and I have a site to site size equal rule to skip.

Hmm, this isn't the 1650 on that machine, it's the last of the 1649 tests.

Update: I incorrectly read the log. Flash requested the SIZE of the file from the source and then blindly tried to send it. I thought in an FXP it would ask the size on the target to figure out if it was there or not or if it needed to be resumed.

[Blubi]

@bigstar
After this update I get "An error occured in FFXP with Invalid image size." on XP SP3 directly after the start.
It only happens without "High color toolbars". When I press on Continue application and activate that option it works.

Also in this version I can't find LiveUpdate in Help menu anymore :(

[benjamin3]

im on 1648 , there's some typo in the announcement look ;-) :

http://i54.tinypic.com/29biq6o.png

^^^^^ seems you were in hurry.. hope all is fine with 1650 .. ;-)

[benjamin3]

Hmm... Can you double check this FXP behavior.

With 2 people sending to a directory I'm watching FXP request the SIZE of the file that got uploaded by another user (after the last directory listing), get a valid size response of the full file size, and then watching FXP try to overwrite the file. No resume, just a plain STOR. This fails because the file is already there, but I don't think I remember flash doing that before.

Both sites are using the global rules, request file/size prior is checked, and I have a site to site size equal rule to skip.

Hmm, this isn't the 1650 on that machine, it's the last of the 1649 tests.

Update: I incorrectly read the log. Flash requested the SIZE of the file from the source and then blindly tried to send it. I thought in an FXP it would ask the size on the target to figure out if it was there or not or if it needed to be resumed.

had similar problems further version or this too, i stopped resuming to same directory cause he just overwrote or "****ed" up the files during resume/overwriting.. bigstar explained then to me why this happens, @bigstar perhaps you can forward the PM to him too.

[bigstar]

Yil and benjamin3, I'll try my best to clear this up.

benjamin3, after speaking to you awhile back regarding this issue the logic was revised, I do believe the changes were mentioned in a forum post or the change log, but I can't recall off the top of my head.

The setting request file size/date prior to transfer serves two purposes.
1. We use this to determine if the file exists.
2. get the current file date/time and size.

We try to use the MLST command if its available and if not we fall back to the SIZE command.

If this setting is unchecked in FlashFXP then we rely solely on the directory listing information, depending on several factors this information could be stale and lead to an undesired results.

That being said this feature has evolved since it was first introduced.

In the original design a command was always sent to the server when this option was checked.

This was later refined to only send a MLST/SIZE command if:
1. the list command was LIST or STAT -al.
2. the list command was MLSD and the age of the cached directory was less than 5 min.

This is when I started seeing reports of issues with uploads being overwrote when multiple FTP users were uploading the same files, so this was then refined again to only apply this logic to downloads. Uploads and site to site transfers would always send MLST/SIZE regardless of the list method or age of the cache.

Now there is one exception to this rule, there is an undocumented ini only setting DGFS that has existed way before the request file size/date prior to transfer setting was introduced and by request this ini setting has been kept.

If this setting exists in the flashfxp.ini under [main] DGFS=1 then the request file size/date prior to transfer setting doesn't apply to site to site transfers.

Apart from the DGFS setting there shouldn't be any reason that FlashFXP doesn't check for the existence of the file. I conducted several tests and as far as I can tell it is working 100%.

If you're still experiencing problems with this setting, I will be happy to investigate this further with both of you.

EDIT: One thing came to mind after my original post.
In the cases where no command is sent to the server is the file to be transferred shown in the target file list? and if it is shown what is the file size? If the size is 0 that could pose a problem.

[bigstar]

@bigstar
After this update I get "An error occured in FFXP with Invalid image size." on XP SP3 directly after the start. It only happens without "High color toolbars".

Thank you, it appears the low resolution toolbars are broken in the new build, I managed a typo in the resource file, so when the image was compiled into the exe it was under the wrong resource name. I will have to issue an update to resolve this issue.

I suspect that this crash on startup is why the update check is missing on the menu, it prevented half of the startup code from being properly executed.

[Blubi]

Working with new update :)

[Yil]

Hmm, DGFS isn't defined in my .ini file so it isn't that, I'll check again with the latest version tomorrow to see if anything differs.

I can tell you that I was FXP'ing between two ioFTPD servers so I know the MLST command would be rejected if sent. At one point I remember it always doing MLST and then trying SIZE/MDTM but that behavior was a long time ago. On the other hand I thought I'd mention it in case there was some logic to give up trying after too many failures which in the upload case would actually be the expected behavior if the files didn't exist...

[Yil]

I tried a few simple FXP transfers and I couldn't get the no SIZE on target problem to show up. I can see that it was broken though by scrolling back in another window but I can't see where it started going bad. It must be something odd like the problem only shows up if it had to reconnect while processing the queue, etc...