Disabling of hidden SIZE command please.

[rco133]

Hi.

In the thread "FlashFXP takes LONG to skip files in FXP mode" in General forum it is mentioned that FFXP sends a hidden SIZE command for every file it tries to transfer.

It is also mentioned that there might be a change to making it optional, so one can turn it on and off.

I have just checked the latest version of FFXP and unfortunately it is still not possible to disable it.

Maybe it is just me using FFXP in a weird way, but when I tell it to skip files in FXP mode, I don't care if the size is the same or if the file is even there. If the directory tree says it is there I would just like it to skip it without further notice.

Now, why is this such a big deal. Well, if you have a directory with lets say 150 files and they are all in both pannels. Then with the SIZE command for each file, it takes like 15-20 seconds to get through the entire list of files (maybe even longer). Without the SIZE command it just takes 1-2 seconds and its done.

Would you please reconsider to make the sending of the SIZE command optional for the user to choose.

Thanks in advance.

rco133

[bigstar]

We determined after extensive testing that disabling the use of the SIZE command resulted in inadequate file exist support, especially when folder caching is enabled.

One thing you could do is use the "folder compare" feature prior to queuing the files to determine which files need to be transferred. This will eliminate the need of trying to transfer files that already exist on the target site.

[rco133]

Hi.

Thanks for the quick reply.

I don't use cached folders at all, and pressing CTRL-D each time is not something I want to do.

In fxp mode I still don't understand why it can't just skip if I explicitly tell it to skip.

So guess I'll just continue to use my ancient version which does not have that feature, or find another solution.

But thanks again for the reply.

rco133

[DayCuts]

As an alternative suggestion (though i dont see any harm in adding a 'dont send size command' option, as long as its noted that it can result in unpredictable file exists rules behavior) xdupe support would be nice.

[rco133]

Hi.

It has been quite some time since I first asked about this. But I try again :-)

Am I really the only one annoyed by this hidden SIZE command for each file transfered in FXP mode ?

I am currently stuck at some old version because in FXP transfers I find FlashFXP really annoying to use in the newer versions that have this hidden SIZE command.

Is there still no move towards making it optional for the user ?

rco133

[bigstar]

There is a unsupported setting that you can set in the flashfxp.ini to disable SIZE for FXP file transfers, although we don't recommend it. FlashFXP uses SIZE to determine if the file exists and if it does the current size.

under [MAIN] add an entry
DGFS=1

[MxxCon]

rco133 (http://www.inicom.net/forum/member.php?u=52276), you've been using flashfxp for at least over a year, how about you buy a license?!
bigstar even implemented this feature on your request, stop being such a cheapass and buy a license already!

[rco133]

Hi.

I have now tried the DGFS=1 setting.

It works better, but it still doesn't do like it did in the good old versions.

If I have the exact same files in the two windows, it will still try to transfer the first file, even though it is already on the destination.

I am pretty sure the old version I used before (before the SIZE command was implemented) just skipped every single file if the file name was already on the destination (no matter what the size was).

Any chance that the behaviour can be like it used to be in pre 3.2 versions. Think the last version without that SIZE command was 3.0.0 build 1015.

And for MxxCon. I actually do have a license, but have been using an old version for ages, since that hidden SIZE command kinda made the new versions useless for me.

But I remain in the hope that it will be possible to get it to do like it did in the past, which was if file exists (no matter what size it has) just skip it. And that is still not what it does with the DGFS=1 setting.

rco133

[DayCuts]

rco133, i am assuming you have double checked your File Exists Rules and that the file SHOULD be skipping according to those rules?

If so and its not skipping still, then I would have to agree, i think if the DGFS setting is defined, then FlashFXP should abide strictly to the File Exists Rules and not attempt to transfer.

You mentioned 'try to transfer the first file', does this mean that if multiple files exist on both sides, that it will only attempt to transfer the first and then correctly skip (if set to do so in FER) over the others without checking the size. Or does it attempt to transfer the others as well? (this could mean a logic/ordering bug of some kind rather than undesired behavior)

[rco133]

DayCuts,

I have double checked my File Exist Rules, and for FXP they are set to auto skip for all three options.

If I select several files on source and they are all on the destination, it is only the first file that it tries to transfer.

Looks like this:

[12:24:55] [L] PASV
[12:24:55] [L] 227 Entering Passive Mode (xx,xx,xx,xx,xx,xx)
[12:24:55] [R] PORT xx,xx,xx,xx,xx,xx
[12:24:55] [R] 200 PORT command successful.
[12:24:55] [R] STOR xxxxx.r85
[12:24:56] [R] 553- xxxxx.r85: This file looks like a dupe!
[12:24:56] [R] Transfer Failed!
[12:24:56] [L] Skip [equal]: xxxxx.r02
[12:24:56] [L] Skip [equal]: xxxxx.r05
[12:24:56] [L] Skip [equal]: xxxxx.r14
[12:24:56] [L] Skip [equal]: xxxxx.r18
[12:24:56] [L] Skip [equal]: xxxxx.r20
[12:24:56] [L] Skip [equal]: xxxxx.r23
[12:24:56] [L] TYPE A
[12:24:56] [L] 200 Type set to A.
[12:24:56] [L] PROT P
[12:24:56] [L] 200 Protection set to Private
[12:24:56] [L] PASV
[12:24:56] [L] 227 Entering Passive Mode (xx,xx,xx,xx,xx,xx)
[12:24:56] [L] Opening data connection IP: xx.xx.xx.xx PORT: xxxxx
[12:24:56] [L] LIST
[12:24:56] [L] Connected. Negotiating TLSv1 session..
[12:24:56] [L] TLSv1 negotiation successful...
.
Some lines here
.
[12:24:57] [R] List Complete: 6 KB in 1,38 second (4,8 KB/s)
[12:24:57] Transfer queue completed
[12:24:57] Skipped 6 files
[12:24:57] 1 File failed to transfer

Should have been Skipped 7 files since all 7 files were already on the source.

It still says "Skip [equal]" instead of just skip. But it is very fast like it was before the SIZE command was implemented. So I guess that the SIZE command isn't sent eventhough the message says "Skip [equal]".

So as you say it might just be a simple issue causing it to try and transfer the first file when it should just skip it according to the FER.

rco133

[bigstar]

Is it possible that the first file didn't appear in the list on both sides? It uses the list content to know which files already exist, so if the file was added after you did your listing FlashFXP wouldn't know about it.

I turned on DGFS and tested this setup and in every test the files are skipped as expected.

The same size comparison is done whether you have DGFS enabled or not, however the method used to get the size is different. when DGFS=1 then we look at the size in the file list, otherwise we issue SIZE to get this value.

[rco133]

Bigstar,

That is really strange. I have tried many many times now, and even if I just take one file and drag it to the other window to transfer it, it will still try to transfer it instead of just skipping it.

And I am 100% sure that the exact same file is in the list in both windows.

Every single time a STOR line for the first file shows up in the log. And if I have put several files in que, then the following files will be skipped like the output I pasted in my previous posting.

I am running 3.6 RC3 btw.

Is there anything I can do to try and troubleshoot why my setup behaves differently than yours.

I have not tried a total clean install though. What I am using is 3.6 RC3 installed on top of some old 3.0 (before the SIZE command was implemented).

rco133

[bigstar]

whats the build number?

If this one is newer try it instead http://download.flashfxp.com/beta/ffxp3.5.3.1225.zip

[rco133]

I was using build 1220.

Have now tried build 1225 and it seems to be working the way it should in that build.

Thanks a lot.

rco133