cw_user01
  • cw_user01
  • 57.8% (Neutral)
  • Fledgling Topic Starter
2010-01-12T12:07:40Z
This is very strange and may be hard to explain so bear with me.

Open RDTabs and connect to a server (have tried it with 3 different 2003 machines)

Open 2 Explorer windows on the host computer (NOT the remote machine).
In the first explorer window I navigate to a local folder (c:\stuff\bk)
In the 2nd explorer I navigate to a network share using UNC ( \\prodserver\application\version1).
In the 2nd explorer I select all files and right click and select COPY
Back in the first explorer I right click and select PASTE
The copy starts. There's about 200 MB of files being copied so it takes a while.
WHILE THE COPY is taking place, I right click in the RD window.
As soon as I right click, I don't see the context menu. ANOTHER COPY STARTS UP.
If I try to cancel it, another one starts up again. And again....I have to cancel about 8 times.

Notes:
If the 2nd explorer window mentioned above is local (i.e. NOT UNC), this does not happen. (or at least I could not make it happen)
All these "unintentional" copies are copying the files from the same source (the UNC location in my example) to "tmp" folders such as:
C:\Users\xxxxxxx\Tmp\_TSB2B9.tmp\_TS5F5E.tmp
C:\Users\xxxxxxx\Tmp\_TSB2B9.tmp\_TS7BE7.tmp
C:\Users\xxxxxxx\Tmp\_TSB2B9.tmp\_TSF7AF.tmp

Each time I canceled the copy, when it would start up again, it would create a new folder.
Now I can understand that the file information is still in the clipboard from the original COPY/PASTE.
It's as if right-clicking in the RD window is initiating another PASTE.

Any ideas?





cw_user01
  • cw_user01
  • 57.8% (Neutral)
  • Fledgling Topic Starter
2010-01-12T12:31:38Z
This can be simplified.

You dont have to initiate the copy between the 2 explorer windows. Just go to the explorer with the UNC, select your files and select COPY.
Now right click in the RD window.

The copy occurs. (to a folder like C:\Users\xxxxxxx\Tmp\_TSB2B9.tmp\_TS5F5E.tmp)

The only reason I noticed it was because I had a lot of files and VISTA was doing it's "Preparing to copy...." crap.
If I just select a few files, the copy occurs in the background without me even knowing about it.

Timothy
  • Timothy
  • 100% (Exalted)
  • Flock Leader
2010-01-12T14:33:19Z
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.
cw_user01
  • cw_user01
  • 57.8% (Neutral)
  • Fledgling Topic Starter
2010-01-12T14:54:08Z
Timothy wrote:

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.



interesting stuff.
I've never seen nor have I been able to reproduce this background copying using microsoft's remote desktop app. And I'm a maniac when it comes to copying / moving files, and remote desktoping. I do so much repetitious stuff, I swear one of these days I'll be replaced by a computer.
full film