indeed :)

I do not think that it would cause problems. I've just meant that it takes time to implement and fine-tune it. And as noone have asked for this so far... :-)

I think it would be nice to be able to background all operations, though I accept that this is quite a functionality change! I don't see any reason why this would create problems, although I suppose that you would need to deal with conflicting operations in the queue. Well actually, I suppose you don't need to do anything special here; for example, if you move a file and, while moving is taking place, you delete it, then the server will just complain when the instruction finally arrives to delete a file which is no longer there.

Currently, only file transfer can be backgrounded.

I do not mind adding the option for file deletion. However then the option would have to be added for all other operations. Because, when deletion, who not moving, etc? And that's quite a change :-)

Hi Martin,

I just noticed that delete operations do not get backgrounded, even when backgrounding is the default transfer option. (I was deleting a few folders, which turned out to have a lot of content, so I had to wait for a few minutes for the operation to complete.)

Is this by design? I think it would be good to add delete operations to the queue, along with normal transfer operations.

Cheers then,
Anton