Disable MDTM check feature on every single file

[benjamin3]

hi there

upgraded old 3.6.x to 4.0 RC1 (latest build) now , backup-restored configuration, everything seemed to be converted fine (anyone can tell me the default FONT in the 4.0 RC1, i like this more, but now its switch bach to MS sans serif 8 ) ;-)

ok lets summarize my problem (perhaps im too dumb to find a thread having similar problems, yes i used the search) ;-) :

during fxp transfers, this MDTM cmd is coming since 4.0RC1 comparing each file, size blabla, some "file not found" is coming but thats clear cause its not "there" in the destination , well this MDTM is quite annoying duration, normally "same" files where skipped quite fast, a whole list flushing down but now it stops on each file.

[R] 213 10001186
[R] MDTM pack01.zip
[R] 213 20100826120646
[L] Skip [rule:8 equal]: pack01.zip
[L] SIZE pack02.zip
[L] 213 12345678
[L] MDTM pack02.zip
[L] 213 20100826120513
[R] SIZE pack02.zip
[R] 213 123465678
[R] MDTM pack02.zip
[R] 213 20100826120913
[L] Skip [rule:8 equal]: pack02.zip
[L] SIZE pack03.zip
[L] 213 12345678
[L] MDTM pack03.zip
[L] 213 20100826120508

and so on...

normally it was :

Equal / skip
Equal / skip
Equal / skip
Equal / skip
Equal / skip
Equal / skip

dont have the proper syntax right now.

am i blind ? where to disable this ?

thanks for helping

[Yil]

This is an interesting issue actually. You see, your v3.6 actually issued the SIZE command behind the scenes before starting each transfer. That's why you don't see 100 instant [size equal] type messages for 2 identical dirs, but they instead show up slowly. The server has to send and wait for a reply for each file individually. Using advanced settings you could disable that in that past (not sure if possible in v4) but it's actually a good thing most of the time and well worth keeping enabled... The question I'd pose is should you SEE that or should it be hidden in the status window. As an FTP server author I want to see everything the client is doing, but I can totally understand (and often want) to not have that spam cluttering things up. An option to hide that query/response sounds like a good thing to me!

The MDTM check is a bit more subtle. I like your suggestion of making it optional, plus another option to hide the spam if enabled! If you don't enable it however adjusting the timestamps on local files is a bit trickier to get right. I think using the timetamp from the directory listing would work well (after using one MDTM to determine any offset being applied) and would speed things up. Allowing you to choose speed over accuracy for a particular site might be useful. I also haven't tested this, but I assume that if you disable the "preserve file date" for the type of transfer you are doing and don't have any time based file transfer rules it won't bother requesting the time via MDTM at all. Even then it could use the directory listing to weed out obvious matches for timestamp comparisons and only request it if tricky to determine...

[bigstar]

In the file transfer rules dialog unchecking "preserve file date" for the transfer type will stop FlashFXP from setting the file date/time on upload also in the same dialog unchecking "request file size/date prior to transfer" will use the information in the file listing which may not be 100% accurate, especially if the folder is cached and its a busy server.

Unchecking these options will give you a very noticeable speed increase but reduce the accuracy of the file transfer rules.

In v3.x the command and reply was hidden from view but a large volume of bug reports were from customers wanting to know why there was a delay, they couldn't see the command being sent and the delay wasn't obvious.

[Yil]

You know, I must have missed the addition of the "request file size/date prior to transfer" option but, being picky, I might suggest making that 2 options since testing the size is pretty important. The date less so...

I can totally believe the issues with hiding the SIZE command (trust me, at times I want to see the details), but perhaps as a compromise you could offer an option to collapse the request(s), response(s), and matching rule into 1 summary line? Or just the FTP part and keep the rule on it's own line. Could look like "FTP QUERY: SIZE=xxxx, MDTM=yyyyyyy". That might convey the same info and let people see what is happening without taking up as much space in the status window since that would otherwise be at least 4 lines... You could even adjust the output to indicate where you got the output from since "FTP QUERY:" is pretty clear, and something like "DIR LISTING:" if you disable the query option... Just some ideas...

[bigstar]

The reason its combined is because on legacy servers where the MLST command isn't supported (which returns the size and date/time in a single command) the SIZE command is used and the date/time is obtained via the file listing.

The capability of the server determines which command is used.

Either way its done by issuing a single command to the server.

The way the output is shown in the session status window doesn't allow for the grouping commands and replies. The purpose of the session status window is to show the raw text, it could always be redone in a way to beautify it but then the user wont be seeing the actual replies from the server and what we display instead.