After cancelling a FTP upload Far freezes

[vkovalcik]

Netbox version 2.1.37 build 309. Tried it with Far 3.0.3900 and the last alpha build 3974.

When uploading and cancelling in the middle, confirmation is shown. When I press OK, directory listing is refreshed (last log file line is: "Directory listing successful"), but the transfer dialog stays visible and Far is frozen. There is nothing that can be done, except killing Far. Could you please take a look at it?

Tested both with and without ConEmu. Passive/active mode has no effect, also tried to disable directory caching, but again no improvement.

[VictorVG]

And you can see how it behaves in the same situations NetBox version 2.1.38 build 313 ( included in the latest nightly build Far or or can be downloaded here:

FarNetBox-2.1.38_Far3_x64.7z - https://yadi.sk/d/QNgp0-fMUNipQ FarNetBox-2.1.38_Far3_x86.7z - https://yadi.sk/d/ieY1OR2YUNitv

archive 7-Zip v9.34 Alpha, LZMA, SOLID, MAXIMUM

? To control the behavior of the program, you can use latest version Process Hacker (PH) v2.34 r5632 Dev (http://yadi.sk/d/193Gnglm4Ia5D) who can control including working network connection (Network tab). Let's see what happens? PH is the only limitation is that if you are running XP, not all of the tools you will be available. All restrictions are lifted on OS Windows Vista / Server 2003 R2 or later. You can install as PH for permanent work and run without installation from a Zip archive. All documentation and necessary for DLL is in my archives (7-Zip v9.30 Alpha, LZMA, SOLID, MAXIMUM). And then let's see what happens during the operation of the complex. I think that the cause of the problem would be simple and we can fix it.

[vkovalcik]

Thanks for such a fast reply! I tested it with your nighly builds, but most of the time it works the same (though in one case, it didn't freeze).

There is no longer a network transfer present. It is definitely not frozen such as waiting for some mutex, because the PH indicates that the Far thread stack changes. This is a place where it is most of the time: http://www.pastel.cz/temp/far_stack.jpg

Not sure, what exactly are you interested in. If you can tell me, what do you need, I will happily help you with the investigation.

[VictorVG]

What we'll see in the stack of threads fine, but we are interested in you what is happening in the sWhat we'll see in the stack of threads fine, but we are interested in you what is happening in the statistics of network I / O at a time when we are working with FTP - connection status on the Network tab http://s020.radikal.ru/i719/1407/4d/18015a12ec1d.png and transmission statistics - Process name - Enter - Disk and Network tab. This will allow us to understand what is happening. Also of us you need to enable logging session in the connection properties.

Excuse me - for urgent cause, and later will be able to continue the conversation. And yet I ask you to make those measurements that we talked about above so that we can see what is happening. Technical option I speak English quite well, so this is how I see the most affordable for you and a way to communicate.

[vkovalcik]

I see, thank you very much, I didn't expected so fast replies at all! These are statistics during the transmission: http://www.pastel.cz/temp/far_disk_net.jpg And just to be complete, here is the log after I cancelled the operation and Far became frozen: http://www.pastel.cz/temp/far_ftp.log

After freezing, the network statistics clear a bit... the line with Far on port 65421 disappears and only the port 21 stays open.

[VictorVG]

Looked writes in the log server - you undertake operation overwrite the file, the plug-in will prompt you for this operation does not receive confirmation from you and handle this situation as "User canceled operation" time in the log 02.07.2014 14:49:37.784. Can you set too short timeout response from the server and the operator whereby triggered defaults in the plug-in?

Connection is on hold, as expected. 21 management port is at 65421 connection is ready to transmit data, but without operator commands plug-in does not send them naturally and waiting for your decision ...

[vkovalcik]

That's not exact - there was a confirmation to overwrite the file and I chose Yes - the transfer went as expected, but after a while I pressed Esc and confirmed that I want to cancel the operation... and then Far got stuck.

Just to be sure, I tried it also with deleting the file as a separate operation and then started the copy operation, but after cancelling, there was the same result - Far got frozen.

Server response timeout was 15 seconds. As you say, I tried to set it to 2 seconds, but still cancel the operation within one second... still freezing. Then I tried to set it to 2, started copying, pressed Esc... wait 5 seconds and then confirm the cancel... again the same thing unfortunately.

[VictorVG]

Increase the timeout server - many FTP servers have a normal response time like 65 - 70 seconds or more, so for remote servers wiser to put a timeout of 90 seconds. With a short time-out protocol does not manage to get a response from the server and fails.

[vkovalcik]

Ok, I have tried to set there 60 seconds, but no change.

But I don't think this is relevant. We are talking about very fast FTP server and also I have 120 Mbit/s connection. For comparison, the old Far FTP plugin works correctly and this is what happens:

Start connection, start copying, transfer in progress (I am waiting), cancelling, Far is responsive again and I can do other things - all of this under 15 seconds.

On the other hand this is what happens with Netbox FTP (the same 15 seconds until the last step):

Start connection, start copying, transfer in progress, cancelling, Far is stuck forever... many many minutes till I kill Far.

It seems to me that Netbox doesn't return control to the Far after reading the file list. If the file is successfully copied, the file list is refreshed in less then one second and Far is again perfectly responsive. It's only the Cancel that screw this up :)

[VictorVG]

For typically FTP server time-out is 60 sec little speed and the server channel is not an indication that it responds quickly. Just when a connection is in the amount he can give up this amount of data including service data protocol, but an indicator that he will answer you in time of your choice it is not. Try to 90 seconds or more.

[vkovalcik]

Ok, I have tried it, but unfortunately with the same result, i.e.:

Connected, started copying, (waited 5 seconds, about 12 MBytes got transferred,) cancelled and confirmed the cancel operation... Far is stuck. I waited for about 5 minutes, but nothing else happens, Far is still stuck.

Just to be clear, I attached a video showing two operations: First there is successful copy operation, then there is the same thing but with Cancel in the middle - this causes the stuck (or infinite loop?) http://www.pastel.cz/temp/netbox_video.avi

[VictorVG]

It looks like the client to the server do not agree :) and the client waits for a response from the server.

[michaellukashov]

Please try current version 2.1.38 which comes with Far3 nightly builds.

[vkovalcik]

Ok, tested today's nighly build of Far with supplied plugins (2014-07-30 x64), but no change ... still freezing.

[michaellukashov]

What about current version 2.1.40.347 ?

[vkovalcik]

Thanks for the update. I have downloaded the current Nightly build of Far 3 with this plugin version, but I am sorry - the issue is still there.