How to better copy&paste big files over RDP?
Solution 1:
When you say a Zip file, do you mean an uncompressed archive that would be the same size as all the individual files? Or do you mean a compressed archive? Because right there, if you are talking about a compressed archive, you'd have a faster transfer, which strictly speaking would be better. Of course, if you take into account the amount of time it takes to make the archive, and how long it takes to extract the archive, then the specs of both machines come into play as to whether the archive is better than loose files.
Now, since you are talking about RDP (as opposed to VNC), the bandwidth usage of the remote connection is quite a bit. RDP is more responsive than VNC, the color depth is (by default) more than 256 colors (32 bit if you don't change it), the screen size will be the size of your desktop, etc... all of these factors affect how much bandwidth is being used just for the remote connection. If you drop things like... the size of the remote desktop, and color depth to 16 bit or less, make sure you aren't sharing sound, etc... this will use less bandwidth for the remote connection, so that when you are transferring files, the remote session should be more responsive.
In the end though, unless you can throttle the file transfer, the remote session is going to get sluggish no matter what you do while you are transferring files, since as much of the available bandwidth as possible is going to be used for the transfer between the remote machine and your machine.
EDIT
You are attempting to find a simple way to transfer files WITHOUT affecting the quality of the remote connection. It doesn't matter if they are large files or small files. At your end (the client machine) you are squirting small amounts of data up to the remote machine (server machine). You know... typing, mouse commands, etc. The server is sending large amounts of data to you all the time, in the form of the images that are making up what you see across the remote connection. So, before you transfer any files, you are ALREADY transferring a large amount of data in one direction. That's why I brought up the things you could do to reduce the amount of data you are transmitting.... namely use a smaller resolution for the remote machine on your desktop (as opposed to full screen).... reducing the number of colors from 32 bit to 16 bit or even 8 bit. Those two steps right there will drop the amount of data you are transmitting from the server (remote) to the client (you). It also means that when you start transferring files along the same connection and route, your remote connection will suffer less.
As I said... nothing you can do will make the connection stay crisp and responsive. Why? Because as soon as you start transferring files from the server to the client, this is going to suck up every bit of bandwidth that is available along that pipe.... and you are already using some of the bandwidth along that pipe for the remote connection itself.
First I tried to copy&paste before midnight when the transfer speed was limited by client computer ISP to 100 kB/s. So, it required a few hours and I was forced to cancel transfer since remote desktop became too unresponsive and sluggish (slow). So, I re-started it over midnight when my local transfer speed is over 4 GB/s
So when you first tried the transfer, you had a download connection of 100kb/s. You were moving 1.2gb of files as fast as possible, which would push to eat up as much of that 100kb/s as it could. Which would leave what room for the data supporting the remote desktop connection? So, of course it would be sluggish and unresponsive. The only thing you are not also taking into account, is the UPLOAD speed of the server. If the upload speed of the server is less than your download speed... and in this perfect hypothetical the route between the server and you allowed for this upload speed to remain constant, as soon as you start to transfer the files, just about all of that bandwidth is going to be eaten up by the file transfer, which will make the remote connection suffer.
Why?
Because there is nothing throttling the file transfer to a specific speed, or a percentage of available bandwidth, it is going to attempt to use every kb/s it can. By the nature of things, this will make the remote connection suffer.
Even transferring the files from the server to a third party (like an FTP server somewhere) would make the connection sluggish during that transfer, because again, as much of the available bandwidth as possible would be allocated to that transfer. Once that transfer was done however, you would be able to download it from the FTP server with no effect on the responsiveness of the remote connection... again because your incoming pipe after midnight is much larger than the server's outgoing pipe.
So, I would try reducing the quality of the remote connection.
Solution 2:
There is an RDP option that creates a link to your local drive on the remote computer. To enable it, start the RDP client, click (Show) Options, → open the "Local Resources" tab. → click "More" → tick the "Drives" checkbox.
After you connect, open Windows Explorer on the remote system. Your local drive should appear at the bottom of the drive list in My Computer. It shows up as "C on your_computer_name".
You can now Drag and Drop files from one system to another.
Solution 3:
I use robocopy on my windows 7 box, using the unc name \\tsclient.
Solution 4:
I think none of these answers really address the question very well.
Microsoft RDP is a protocol that is not really well optimized for file transfer. If your connection is a little slow, the moving of the file bits, which travel over the same network pipe as the UI packets like the screen draws and mouse movement, may cause one of these things to time out; and then, the server will assume you have lost your connection and will disconnect you, breaking your IO channels. This of course makes the problem worse.
Primarily, you should consider your workflow and see if you have an easier way to move the files over another channel (like over the internet to your server instead of from your workstation) that doesn't violate your security policy.
If you decide that you must use the RDP file-copy channel, then follow these guidelines which work pretty well for me.
- Do not access large files directly over the UNC path to the client. For example, enabling shared folders and accessing the file from \TSCLIENT\share. This pushes the large file content over the small multi-use pipe.
- You will gain a little optimiziation and stability by mapping a drive. For instance, NET USE X: \TSCLIENT\Share will map a drive X: to the above location. Still, overloading the network pipes will disconnect you and disconnect your drive mapping as well.
- Most importantly, when starting the RDP client, choose the network bandwidth setting "Modem" or "Slow". This will much better optimize the file transfer and sound channels, so that they cannot clobber the rest of the pipe used for the UI control.
- On the OS X Microsoft Remote Desktop client, this setting is strangely unavailable. In this case, install MacPorts and run sudo port install rdesktop and then you can connect with rdesktop and the -x m setting (set the "experience" level to "modem or 28.8K")
- If you follow the above recommendations, you will now have a connection optimized for stability and pushing large files will not disconnect you. Now, use a more controlled way to copy the files than copy/paste or drag-and-drop: for instance, try **XCOPY X:*.msi C:\Install** to copy items matching a filename pattern into the specified local (server) directory.
I hope someone finds these suggestions helpful. They certainly work for me.
Solution 5:
As suggested in his answer by @Tom, it is preferable to D&D the files instead of C&Ping them. This has the added benefit of circumventing a bug that interrupts the file transfer if you use Ctrl+C on the client machine.