ABOR LAG

[mikey84]

Hi, i was very glad to see new forums are operational and ppl ressurected the project.

To get to the point, in FXP mode when lets say transfer started of a "file" from SRC to DEST.
Durning the transfer file gets deleted on SRC. Rush issues command ABOR (rush or maybe server).
This resolves in rush lagging on that for quite some time and doing nothing, not continuing the transfer nothing.
Also making "0byte" file on the destination.

Is there any way to resolve that issue? And if such error happens, make rush delete "0byte" file on the destination?

I hope i described the problem clear to understand.

Looking forward to replies.

[LeXxX]

Hi, i was very glad to see new forums are operational and ppl ressurected the project.

To get to the point, in FXP mode when lets say transfer started of a "file" from SRC to DEST.
Durning the transfer file gets deleted on SRC. Rush issues command ABOR (rush or maybe server).
This resolves in rush lagging on that for quite some time and doing nothing, not continuing the transfer nothing.
Also making "0byte" file on the destination.

Is there any way to resolve that issue? And if such error happens, make rush delete "0byte" file on the destination?

I hope i described the problem clear to understand.

Looking forward to replies.

Havent been able to recreate the problem... But depending on what ftp-prog in use, on some there are zip-scripts and such that can disable 0-byte files.
Also in FTPRush, Option -> Misc. -> Check "Remove 0 byte file..."
try is this works

[mikey84]

Its enabled, no solution for the problem thou.

[LeXxX]

Its enabled, no solution for the problem thou.

Whats the ftp-prog in use?

[mikey84]

glftpd, and yes, id imagine zipscript would delete those, yet it doesnt.

Lets skip zipscript for now tho, as rushs "remove 0byte file" function should take care of that, yet it doesnt.

[JohnK]

Yes mickey84, let's forget about 0byte files which is just not the big part of that problem.

I don't have a current log of that bug but it happens often when a file or dir being transfered gets deleted on SRC site which may result in some cases including messages "Timeout, connection closed" in loop mode until it's manually cancelled/disconnected.

[mikey84]

Yes mickey84, let's forget about 0byte files which is just not the big part of that problem.

I don't have a current log of that bug but it happens often when a file or dir being transfered gets deleted on SRC site which may result in some cases including messages "Timeout, connection closed" in loop mode until it's manually cancelled/disconnected.

Exactly

[JohnK]

Here's a mini log (i was in front of the screen when it happened, that's why it's short sorry)


(19:15:26) [1] RETR xxxxxxxxxxxxxxxx.abc
(19:15:26) [1] 550 xxxxxxxxxxxxxxxx.abc: No such file or directory.
(19:15:26) [2] ABOR
(19:16:26) [2] Timeout, Connection closed
(19:17:26) [2] Timeout, Connection closed
(19:18:26) [2] Timeout, Connection closed

... and so on in loop mode with duration of the timeout ftp reply setting in preferences.


The 0byte files are only the result of that bug, normally rush just deletes automatically a failed transfer.

[Thormy]

Confirmed, this is happening to me very often, too. And without manually canceling the transfer and disconnecting from the server, the lag won't go away :/ Fixing this would be a BIG improvement to FTPRush.

[DunderKlumpN]

I Agree, ive got the same problem.