Re: unrecoverable ftp timeout

Hello Joerg,


On Wed, 05 Sep 2018 11:47:01 +0200 Joerg Thuemmler <[email protected]> wrote:

> Am 05.09.2018 um 10:12 schrieb wwp:
> > Hello Joerg,
> >
> >
> > On Wed, 05 Sep 2018 09:50:09 +0200 Joerg Thuemmler <[email protected]> wrote:
> >  
> >> Am 03.09.2018 um 11:34 schrieb wwp:  
> >>> Hello!
> >>>
> >>> there's something I'm experiencing quite frequently now, I'm not sure I
> >>> was facing this behaviour w/ former versions: it's losing the FTP
> >>> connection after a while being inactive then there is no way to free the
> >>> VFs from the 'Active VFS directories' (it's listed in) and there is no
> >>> way to re-instantiate the connection again.
> >>>
> >>> If I try from the 'Directory hotlist', I get a:
> >>>     Cannot chdir to "/ftp://...."
> >>>     Remote I/O error (121))
> >>> if I try from 'FTP link...', I get only:
> >>>     Cannot chdir to "/ftp://...."
> >>>
> >>> The only way I've found to reconnect to a lost FTP connection is
> >>> restarting mc, which is not convenient nor expected.
> >>>
> >>> mc 4.8.1 compiled from the sources, on am up-to-date CentOS7 box:
> >>> $ mc --version
> >>> GNU Midnight Commander 4.8.21
> >>> Built with GLib 2.54.2
> >>> Using the S-Lang library with terminfo database
> >>> With builtin Editor
> >>> With subshell support as default
> >>> With support for background operations
> >>> With mouse support on xterm and Linux console
> >>> With support for X11 events
> >>> With internationalization support
> >>> With multiple codepages support
> >>> Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs
> >>> Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
> >>>
> >>>
> >>> Regards,
> >>>  
> > [snip]  
> >> Also I noted ftp servers, which do block the connection after some idle time and if you try to use this connection, they want you to reconnect and to put in your password once more. Mc caches your pw and resends it, but the new connection is started in the ftp users root dir (on the ftp server) again, not in the dir you last used. That may confuse the vfs system, but it's a problem connected with the ftp server's usual behavior (mc could resend the "cd" commands then after reconnection, dunno whether it's possible to cache last dir before timeout disconnect).  
> >
> > I experience this specific behaviour quite often (back to root or
> > parent folder).
> >
> >
> > [snip]  
> >> I would try to get a later timeout on the used ftp server, as I believe it's an old "feature" and will not be changed next time, espacially as sftp will become a more important ftp replacing... Maybe you should change some other properties of your ftp servers making trouble if you try to re-connect. But this depends on ftp server program used.  
> >
> > I'm afraid I can't change anything on the FTP server side, it's not
> > mine at all.. All I know is that mc is not behaving correctly (and
> > possibly differently than "before"?) - I don't face such issues w/
> > filezilla against the same FTP servers.
> >
> >
> > Regards,
> >
> >
> >
> > _______________________________________________
> > mc mailing list
> > https://mail.gnome.org/mailman/listinfo/mc
> >  
> 
> Hi,
> 
> filezilla is disconnecting too after timeout? AFAIK it has a "heartbeat"-feature preventing disconnects by timeout. That was to be my next idea: run some "heartbeat" on your side, e.g. a "ls" cmd via ftp to prevent from connection timeouts...
> 
> yes, it's a "quick & dirty" workaround, but IMHO the "reconnect" problem is in mc since I'm using it...

You're right, it seems to use a keep-alive thing!


Regards,

-- 
wwp

_______________________________________________
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJbj6kWAAoJEEnFZ+hWA4VJSdcP/1rmpuwLmplLDTeoiE91z/4E
OOyKWF5cwQ8Ot8bNHGAHuKvSGYZFVZ8u/mrYu9uG7xVcQeXFvceSwiYJJyigZYeg
Iznlmn2OpCdaw0zlqObW1xFLuJz3Kxgtsa0sap3esAYd9E1bUwfZDawc3wHpwQIL
d34XXWHFoIklfPXbOu2PoKszQxR4G/5G3VCDkc8xSbLWpce/lYfdV0GG8HdK/yrC
QqFzkAwfakHyscPo/xnCDOqavBNYRIN2SDWIPj9C27euzFWsRUOVuKQvbvodJRqP
4sj9bECz4voWGNfUM5Z8ygjKTyyD1G5Ry/jU07R0Jp33Z6mGK843+jfrYcSUeqXK
PQdH3+I2tG1jA9CwBektKj0pHSaL8j1FZJazYian0yXHbLbi6hsGEiW10B1k5DSt
Uwh83jMIH3xva3PCj+5BIrzzFnaKU4gP3qrP8vNkHUlHtyVsX40y9I/B1cWqxfqm
7/FnLuQIbcdr50BGl0pzrQRpQaL1K2RRU+NpsYrWEEiiX/bMD3yn3QcgWHP8EyOu
Q6sehzAZ35x2qXWLNkl0/XkhKqW6aec9Habh3bWZvEQf02dbM8kKLg3JP7jty3Pa
6n6PAlDaXdUzqhND4uNKXCVcvntoDiTaPuVjRHqhuBlWSvHq/QbUAn4rKLQeIvfk
ozRrfCpDMalvU+MtUuB0
=rZt1
-----END PGP SIGNATURE-----