Page 1 of 1

RS_CHECKLOGIN (and clear queues) not fully working

Posted: Tue Feb 09, 2010 2:01 am
by JohnK
Hello again.


I think i have noticed that param RS_CHECKLOGIN isn't 100% respected if a site of the current list is disabled and/or skipped (according to skiplist) when multiple commands are sent with RushApp.FTP.Transfer.

I have tried to set RS_CHECKLOGIN in my transfer lines, but this seem to occur as i explained, so you end up
with twice (ore more) SITE1>>SITE3 transfer with off course in each tab some queues respecting the parameter.

Or is it just a limitation of queueing per combinations ? (like 5 times same queues for same couple of sites)


Another bug :

BTW, is it me or removequeue doesn't always remove queues ? I can't explain when this happens particularly
(if not being a result of a missed RS_CHECKLOGIN afterall), but maybe it's same cause as when not being
able to clear manually (with right click "Clear Current Queue..."), and you have to disconnect one or both sites
to get the queue cleared.


One more possible other bug :

in menu "Auto reconnect if getting these replies" (preferences / connection)
If i add "426- Socket is closed" (to reduce the lag between next commands),

my short log will explain what happens :


(04:18:26) [1] RETR xxx.abc
(04:18:26) [1] 150 File status okay; about to open data connection from
(04:18:30) [1] 426- Socket is closed
(04:18:30) [1] SITE1 Disconnected
(04:18:30) [1] Connecting to SITE1
... SITE1 RELOGIN SEQUENCE...
(04:18:32) [2] 226- | - CRC-Check: BAD!
..
(04:18:32) [2] STOR xxx.abc
(04:18:32) [2] 200 PORT command successful.
(04:18:32) [SITE1 -> SITE2] Transfer Failed: STOR xxx.abc
(04:18:32) [1] STAT -l
(04:18:32) [1] List Complete: 2,443 bytes in 0.03 seconds (78.81KB/s)
(04:18:32) [2] STAT -l
(04:18:32) [1] STAT -l
(04:18:32) [1] List Complete: 2,443 bytes in 0.08 seconds (31.32KB/s)
(04:18:32) [2] STAT -l
(04:19:32) [2] Timeout, Connection closed
(04:19:32) [1] STAT -l
(04:19:32) [1] List Complete: 2,450 bytes in 0.03 seconds (79.03KB/s)
(04:19:32) [2] STAT -l
(04:20:32) [2] Timeout, Connection closed
...

and same forever every minute (or length set for timeout reply), or at least for a long while
until cancelled manually with a forced disconnection on SITE2.

Trying to add "Timeout, Connection closed" in same menu, has no effect either
on that infinite hanging loop.