FlashFXP 4.1 build 1548 stable - Page 2

jharmen · 09-22-2011, 07:20 AM

Quote:

Originally Posted by 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 · 09-22-2011, 08:32 AM

Quote:

Originally Posted by TuSSy

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 · 09-22-2011, 09:07 AM

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 · 09-23-2011, 03:53 AM

Quote:

Originally Posted by bigstar

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 · 09-23-2011, 04:25 PM

Quote:

Originally Posted by TuSSy

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 · 09-23-2011, 04:25 PM

Quote:

Originally Posted by 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 ?

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 · 09-24-2011, 05:29 PM

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 · 09-24-2011, 11:34 PM

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 · 09-25-2011, 06:00 AM

@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 · 09-25-2011, 07:48 AM

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

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

benjamin3 · 09-25-2011, 07:50 AM

Quote:

Originally Posted by 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.

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 · 09-25-2011, 09:42 AM

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 · 09-25-2011, 09:45 AM

Quote:

Originally Posted by 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".

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 · 09-25-2011, 04:07 PM

Working with new update

Yil · 09-25-2011, 09:26 PM

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...