Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review

Anton P.

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... :-)
Anton P.

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.

Re: Delete operations should be backgrounded

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 :-)
Anton P.

Delete operations should be backgrounded

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,