ftp - Test connection before starting Operation

[schittli]

Good afternoon

Totalcommander still has a strange order of handling ftp-commands:
1. Try to execute an ftp-Command
2. Ask to reconnect

It would be nice to change the order:
1. Try if the connection is OK
2. Aks if it should reconnect
3. execute the ftp command.

It would also be nice to have a configuration:
FTP: "Always automatically reconnect": Yes / False

Kind regards,
Thomas

[ghisler(Author)]

1. Try if the connection is OK

Unfortunately there is no such thing like "is there a connection". To check that, you have to send something across the connection, and check whether it works or not. This is because of how internet connections work: They are not a wire, they are packets sent across the network. Only when the server sends a FIN packet (end of connection) or RST (connection reset), then the client side knows that the connection is closed. If the DSL connection was hung up, or there was some other kind of network error, then the client is NOT informed about the connection loss.

[schittli]

Thank you very much for your answer & explanation.
But what about:
- sending a command like pwd to test the connection?
- the Config-Flag to automatically reconnect?

Thanks a lot & kind regards,
Thomas

[sqa_wizard]

2schittli
OK, do you mean:

1. Try to execute an ftp-Command (pwd)
2. Ask to reconnect

Well, that is how it already works (as you stated above)

[schittli]

Hi sqa_wizard

Thanks for your answer... you're probably right, but my point is,
that we I don't have to say (estimated) 50 times / day

"Yes my dear TCMD, please reconnect, I did not started an
ftp-command just for fun".

We have some external ftp-servers with very short idle-Timeouts
and it would be nice if this question will be answered automatically.

Btw.: This would be a solution for a 2nd problem, too: TCMD has
very often broken ftp connections (FileZilla works stable with the
same servers but is not so handy as TCMD) and therefore we often
have the following problem:
1. Start an ftp-Transfer
2. Go and get a coffee
3. Come Back and see the Question: Should I try to reconnect and
should I try to continue?

... if we start a Task, then it's for mor than 99% because we would
like to finish it, therefore we always click Yes, try to reconnect, and
Yes, please continue...

Thanks a lot & kind regards,
Thomas

[ghisler(Author)]

So you suggest that Total Commander should send pwd before each single command it sends to the server?!?

[SanskritFritz]

No, the suggestion is, that TC rebuilds the connection automatically on disconnect, instead of asking the user. It is very annoying to answer an absolutely unnecessary question. TC should try to reconnect, say 2 times, and display an error message if unsuccessful. Needless to say, I very much support this request!

[horizon]

vote for and autoreconnect autoresume in case of failure/disconnection/timeout.
Optional (3 by default) number retries after optional (10 seconds by default) waiting... sounds good for me.

[Clo]

2SanskritFritz

Hello !

No, the suggestion is that TC rebuilds the connection automatically on disconnect, instead of asking the user.

• I agree, it's that I inderstood too.

- I support, of course…

- IIRC, a similar issue has been discussed in the private Alpha-ß forum, but nothing had changed…

 KR
Claude
Clo

[StatusQuo]

The thread including the author's answer where the problem is:
http://ghisler.ch/board/viewtopic.php?p=65369#65369

[schittli]

Thanks a lot for all your replies...

I think this discussion:

The thread including the author's answer where the problem is:
http://ghisler.ch/board/viewtopic.php?p=65369#65369

was too low-level. If we focus on the user, we have only 'simple'
operations: copy, delete, rename, view/edit

So I expect that TCMD act something like that:
1. Note the next user command (copy, delete, ...)
2. Try to execute this command
3a. All OK? » Go on with the next user command
3b. Failed? » Reconnect and execute the noted command again

Another idea: is it possible to make a FileZilla-Plugin?
It is very stable and hard to break.

Kind regards,
thomas

[SPeller]

Ok, implement the option "always automatic reconnect" with big red (or any aggressive color) exclamation box

it can happen in the middle between some PORT and LIST command - you can't just reconnect and resend the LIST command, you have to resend from the beginning, starting with username, password, switching to the correct subdir, binary mode, port etc. etc

Let the user to choose on his own risk. Or implement the list of servers where the case with incorrect path resolving occur to use not autoreconnection. In all my using WC/TC - I never seen a case when reconnection place path to another directory.

[schittli]

I'm sorry, but I don't see the problem: TCMD always knows everything about both files:

- The path & name of the sourcefile
- The path & name of the destination file

FTP can break everywhere - after a reconnect the path to the involved file has to be set
again and then the work can go on... did I miss something?

(It's exactly the same procedure which I have to do manually)

Kind regards,
Thomas

[TLis]

Maybe we could have an INI file flag (e.g. FTPReconnectCount) set by default to 1, and indicating the number of connection attempts (done automatically, before the user is asked, if TC should reconnect. If the answer is YES, then it should start another sequence of reconnection attempts. Then:

With FTPReconnectCount = 1 (default), TC asks the user, whether to reconnect or not after every failed attempt to connect.

With FTPReconnectCount = 10, TC will make 10 attempts, before asking this question to the user.

For all-night-long downloads, the user might set FTPReconnectCount to, say, 1000 letting TC try to reconnect until dawn. Then, if the user sees the question in the morning, he or she would know, that TC really tried hard to connect