Losing Remote Site Directory During Uploads

[foxtail22]

Running 3.0 b7 using passive mode. MTU=1492, both client and server are behind Linksys NATed routers(use external IP feature is great). Ports are forwarded on both ends. Client=XP Media. Client is on 3000/250 cable, server is on 600/6000 DSL/PPPoE. Server is DLink DNS323(Unix L8)

I have seen this twice. While uploading folders containing 15 to 30 - 50-150K JPGs files to the server, the remote directories disappeared and the message "not connected to any server" appeared. The up load continued and completed successfully each time. Refresh would not show directory. Had to disconnect and reconnect to see folders and files.

[foxtail22]

Command: PASV
Response: 227 Entering Passive Mode (69,0,81,244,255,225)
Command: STOR dns323_firmware_103
Response: 150 Opening BINARY mode data connection for dns323_firmware_103.
Response: 421 Timeout (120 seconds): closing control connection.
Trace: Unexpected reply, no reply was pending.
Error: Disconnected from server
Response: 226 Transfer complete.
Status: File transfer successful

[Alexander Schuch]

FileZille uses one command connection for browsing the FTPd and one further connection for each parallel transfer. My guess is that you were uploading but at the same time NOT browsing the FTPd. Because of that, the command connection used to browse the FTPd timed out - this is normal.

[mwrmwr]

I understand the technical "Close" ing comment, but this behaviour is very offputting. In particular when udertaking a large number of transfers during which there is user inactivity and reluctance to disturb a happy download, it is nice to refer to the remote filesystem names. Usability is losing out due to a strict interpretation that demands the remote panel is only shown if the connection remains active.
a) consider italicising the remote panel if there is no active connection
b) consider a much higher disconnect timeout default. It currently disconnects within a minute or two rather than 30 minutes which is more tolerable.

...clicking a ".." or sub-folder in the disconnected-remote panel would obviously need to re-establish a connection at the required point in the hierarchy. The current implementation requires tedious re-navigation as the hierarchy is wiped away and paths and column widths (if filenames are long) have to be re-established etc..

[mwrmwr]

I understand the technical "Close" ing comment, but this behaviour is very offputting. In particular when udertaking a large number of transfers during which there is user inactivity and reluctance to disturb a happy download, it is nice to refer to the remote filesystem names. Usability is losing out due to a strict interpretation that demands the remote panel is only shown if the connection remains active.
a) consider italicising the remote panel if there is no active connection
b) consider a much higher disconnect timeout default. It currently disconnects within a minute or two rather than 30 minutes which is more tolerable.

...clicking a ".." or sub-folder in the disconnected-remote panel would obviously need to re-establish a connection at the required point in the hierarchy. The current implementation requires tedious re-navigation as the hierarchy is wiped away and paths and column widths (if filenames are long) have to be re-established etc..

[Alexander Schuch]

FileZilla Client doesn't disconnect the "browse connection" - the FTPd is. So if you want longer idle time (or disable it alltogether), re-configure your FTPd and it will work out.

I do not get the part about re-establishing column widths as the GUI doesn't change them. If the FTPd disconnects, they stay the same. Furthermore (I just tested with manual disconnects) if the "browse connection" is disconnected, I can just hit "reconnect" and FileZilla 3 beta11 reconnects the "browse connection" to where it was disconnected - same server, same user, same directory.

If you believe it is important that FileZilla 3 keeps the remote directory listing even if the "browse connection" gets disconnected, please file a feature request about that. Thanks.

[mwrmwr]

re: >re-navigation as the hierarchy is wiped away and paths and column widths have to be re-established

Apologies - I cannot recreate that either. I've no clues as to what led me to believe that unless I was switching between FZ3b11 and FZ2 in trying to workround something else and got confused. It was maybe the same brainstorm that caused me to post the same message twice.

Thanks ci-dev/501368 for pointing out about FTPd being the timeout agent
("Error: Disconnected from server").
Perhaps if this message had said "network or remote server has disconnected this client" (as opposed to the notional message if local system is shutting down of

"This client has disconnected itself from the network")
I might have understood the model of operation more precisely.

I see we have a new release candidate... :-}

Mark