If you start uploading a file and you lose network connectivity for a couple of minutes when the network comes back up the download doesn't restart or error it just hangs. (happens in both single transfer mode / multi connection mode)

Issue 2:

When dealing with a hung connection the only way to close it down is to close FTPRush totally (you can't close the connection tab)

Issue 3:

When finished transferring a file and even after closing the connections in a tab, the tab still has the icon of transferring (2 arrows) and you can't close the tab

Issue 4:

When sending a folder full of files to a server, eg /root/folder/<files> and you queue up the folder from /root/ when the transfer is finished FTPRush doesn't always CWD back to /root/ and sometimes stays in /root/folder/

If you connect to an ftp site, and transfer a file, the transfer connection remains open. When you disconnect the transfer connection continues to remain open, until you close the window, or until it eventually times out.

If you reconnect before it times out, and transfer a file, that file gets put where ever that other connections transfer connection was pointed at.

This happened most noticeably when I was changing the username and password of the same connection, and connecting to different accounts, but on the same FTP.

1: Connect to ftp with an account.2: Transfer a file.3: Disconnect.4: Change the username/password so you're now using a different account, with a different home directory (but maybe both say /).5: Transfer another file.6: Watch as the file is transferred into the home directory of your first account, and not the actually connected directory of your second account.

Changing the settings to "disconnect on transfer" meant that it disconnected my transfer threads, and my control thread. This was very annoying.

Had a lot of annoyances with this today. Basically made it unusable for me.

For me CHMOD is not working. I am connecting to a server using the SSH protocol. I had to use putty to change the CHMOD on the files. Anyone else noticed this problem? Using both installed and portable version on both Windows 7 32 and 64 Bit.

OK, I was able to show and change the CHMOD using FileZilla and WinSCP . Must be a problem with FTP Rush.

As for the lockup someone here is having. I had that also with 2.1.2 and with portable only on Windows 7 64 Bit, but the installed version worked fine there. On my Windows 7 32 version, it was other way. Portable worked fine, but installed version just hang on disconnection.

- If you click on the Abort button :1. Immediately resets the queues columns "Transferred" and "Size"2. Will stop the current queue item from transferring, but will often simply start the next one in the queue.

- If you abort an upload, and then restart the upload, even if your File Exists Options are set to "Auto Resume" on Target file is smaller, it never does and always does an Auto Rename instead.

- If you double click on the border of a queue column to resize it, it will be resized, but will also now sort by the column name you were resizing.

"Stop and resume if no data recieved" option does not seem to work. No attempt or reconnect is happening. Possibly related to post #1. In some cases no errors visible in the FTP log, sometimes a [T]"426 - Data connection closed" error appears. Can not remember exact error message, but error code is correct. Happens often, so can c/p if needed.Multiple time increments have been tested.

When transfering a queue of folders (not empty), sometimes an empty folder will be transfered, and the element is removed from the queue as being tranfered correctly. The data within the folder is just skipped and im left with an empty folder.Furthermore:When transfering a queue of multiple folders, in some cases 2 dirs are created at the target path (both when down/uploading locally and FXPing) In most cases the files within that 2nd folder is being added to the queue, but in some cases this folder is also being skipped as transfered correctly.

In version 1.1.3, when resuming Windows which was hibernating/on standby, and a transfer was in progress, this transfer would resume when Windows was started again.