Hello!  I just built a Windows 10 VM and have installed the client.  I've always used the move on complete feature to transfer what I download to a desired file share.  This has worked flawlessly for years.  Anyway, on this VM, the file transfer speed is terribly slow when it tries to move the file using the move on complete feature.  After cancelling the move on complete, I then manually copy the file to the mapped filed share.  This process flows at the expected speed.  I'm running the latest version.  I can try an older version if I knew where to download an older version.  

Thanks!

What kind of share it is? Typical SMB connection over host-guest network? Or some virtual pseudo-share that needs guest drivers from the VM? Is it an Explorer shell extension (not an actual mounted file system)? Do other tools, like console copy or Total Commander, work as fast?

Thanks for the reply.  The share is nothing special.  It is just a shared folder on my NAS.  I am mapping to it via windows drive mapping so it has a drive letter. z:\ = \\ip\sharename.  All other machines work fine with the move on complete feature.  It is just this VM that has the issue.  This VM is running on another NAS.  So the file transfer is going from NAS to NAS over 10GB ethernet.

@guest, why ask all this? op said tixati move is slow, explorer ctrl+x is fast

Well, if you are so smart, go solve the OP's problem without asking questions, and I'll just watch.

Network file systems have a lot of hidden pitfalls. For example, you expect to overwrite a single small part of the file, and operating system decides that it needs to check that it has no active write locks before sending the data, for which it initiates the query operation to the server, which (being, say, a Linux NAS) gets a bit puzzled, but initiates an enumeration of local user account and their file locks, finds no such user there, and responds that it agrees to write the data, and only then it gets sent. A small write might cause a lot of network traffic and system activity that no one thought to be repeated often.

You can try to compare the SMB traffic of Explorer and Tixati in Wireshark, it might be something obvious. Also look for DNS queries and connection attempts to non-existing controller domain names. Your DNS server might decide to take a lot of time searching for them on the Internet instead of replying instantly that those do not exist. Changing the supported SMB versions on both sides might make it use a dumber protocol. You can also test some buffer and parallel queuing tweaks.
https://serverfault.com/a/808751

Assuming it is Tixati that is waiting synchronously for each tiny write to be confirmed by the server for some reason, you can test certain things to make things clearer for the author.

Is performance the same no matter which file allocation method is chosen? You should probably test the whole process from start to finish by downloading the test torrent(s) multiple times.

If you move some existing fully downloaded torrent from the local drive to the network drive manually, is it the same?

If you stop such torrent, and move it in the stopped state, is it the same? (I'm not sure whether Tixati uses the shortcut to move the whole file through a system call instead of moving piece by piece internally.)

Thanks everyone.  There is no need for this back and forth.  I just don't use this feature on the VM and just manually copy and paste to the mapped drive.  End of discussion.

@guest you should have written the network storage details without the "well if you are so smart..." line

not everyone will know everything, none is born with knowledge.

these things of network storage and transfer that you know, how did you find them? if this talk has to happen in private, are you on any tixati channel or do you prefer irc for this talk?