Although you are correct that an actual "copy" is taking place, it is only the cache that is being updated. So when you right-click in the new desktop, the clipboard prepares for a possible paste. It shouldn't, but it does. It's annoying as hell. If you let it go to completion, you will see that no "paste" actually takes place other than to the temporary folder that is filling its file cache to prepare for you to press paste. If you pressed paste after that, the actual paste operation would be instantaneous, as it would be copying from the previously prepared cache, instead of over the network.Unfortunately, this is a limitation in the Remote Desktop Protocol at this point when a remote computer is not on the same subnet that you are and you right click in Explorer. If you are on the subnet and the computers can speak SMB/CIFS to each other, the paste operation is delegated to SMB/CIFS, instead of over the RDP, so the operation is much faster. The same behavior will occur with Microsoft's remote desktop client on all versions, even the newest Windows 7 version.I wish Microsoft would fix this. What should happen is a right click does nothing until the user actually presses "paste" but unfortunately, the way the clipboard is designed, it immediately prepares its cache as soon as it is tickled, instead of waiting for the user action. I think this is because Explorer is querying the clipboard to see if the contents contain a file. If it contained only text, for example, the "paste" option would be grayed out. That's a lot of overhead for graying out a context menu entry! :-)As to why it retries eight times -- I don't know. I wish "cancel" would cancel. The only thing I can think of is that rdpclip.exe (the remote desktop's clipboard integration tool) assumes that network conditions or something like that messed up the transfer, so it tries again.There is no good resolution to this until Microsoft fixes the issue in the protocol and API itself.