Deleting folder with Permission Denied looks like it worked

Using SmartFTP v3.0.1033.0, if I delete a folder that I don't have permission to delete, it still disappears from the SmartFTP folder list, even though the log does display the 550 error:

[16:12:06] RMDA test
[16:12:07] 550 /test: Permission denied.

Refreshing the list shows the folder again. Deleting a file in the folder also fails with 550, but the file does not disappear from the list.

Trying to copy a new file into a folder where permission is denied actually continues retrying the transfer:

[16:25:54] Remote file exist check: "handles_1.log".
[16:25:54] MLST handles_1.log
[16:25:54] 550 /test/handles_1.log: No such file.
[16:25:54] Compression disabled for private IP addresses.
[16:25:54] PASV
[16:25:54] 227 Entering Passive Mode (10,0,0,2,110,204)
[16:25:54] Opening data connection to 10.0.0.2 Port: 28364
[16:25:54] STOR handles_1.log
[16:25:54] 550 /test/handles_1.log: Permission denied.
[16:25:54] Transfer failed.

This retries every 30 seconds.

Ignore Errors is Disabled.

I'm hoping I've missed an option somewhere, as this is the first FTP client I've ever come across that doesn't tell me that it can't complete a command.

>[16:12:06] RMDA test
>[16:12:07] 550 /test: Permission denied.
The bug fix will be incorporated into the next release (couple of days).

The other problem I do not understand. The "Ignore Error" feature only applies to the Remote Browser and not the transfer queue.

I was probably incorrect in assuming that Ignore Errors may have an impact. It's good to know it's just a bug and will be fixed.

With the second problem, if I try to transfer a file to a folder that does not have write access, the transfer goes into the queue, fails, then retries every 30 seconds. Because the log shows that the server did return a 550, in theory the transfer should have been aborted in some way and paused on the queue.

I've been testing SmartFTP to replace my current client, which I've been having lots of problems with. These were the only problems I could find, and there was lots about SmartFTP that I liked.

>I was probably incorrect in assuming that Ignore Errors may have an impact. It's good to know it's just a bug and will be fixed.
This is by design. The Ignore Error option does not have any effect in the transfer queue.

>With the second problem, if I try to transfer a file to a folder that does not have write access, the transfer goes into the queue, fails,
> then retries every 30 seconds. Because the log shows that the server did return a 550, in theory the transfer should have been aborted in
> some way and paused on the queue.
This is by design as well. There is a max retry count. If the max retry count is reached the transfer will not longer be retried. While it is easy for a human to make the decision whether the transfer should be paused/aborted or retried it is quite hard for a program. Also consider the fact that FTP servers return random and sometimes incorrect replies. For example a "permission denied" error does not necessary mean that there are insufficient permissions. It might be a temporary error as well.

The new version with the delete fix is available now: https://www.smartftp.com/download