Major Description
In current 1.40 architecture there was optimization added to fast-move directories/files before scanning their content.
This however broke the ordering of tasks' execution as the fastmove-able tasks are executed out of order with "Read tasks size before blocking" option set to Yes. That causes problems for some specific scenarios that performs a copy and then move of the same data (move is completed before copying finishes).
There are several solutions here to consider:
1. Add option to disable fast-move (fastest to implement, not really good in the long run as we lose the optimization).
2. Exclude fast-move from the "before blocking" phase of task processing. This will enforce ordering, but will unnecessarily scan for all files if fast-move is possible. It should be possible to configure this behavior though.
2a. As above, but with scanning disabled if we detect that the paths are candidates for fast-move operation.
