Microsoft RichCopy

“RichCopy is a free utility that comes to us from Ken Tamaru of Microsoft. The tool was first developed in 2001 and has been updated regularly to keep pace with evolving needs. Trust me when I tell you, this is the answer to all your file copying needs. What you'll find most striking the first time you take RichCopy out for a spin is that it's a multithreaded copying tool. That means that rather than copying one file at a time in serial order, RichCopy can open multiple threads simultaneously, allowing many files to be copied in parallel and cutting the total time required to complete the operation several times over. You can also pause and resume file copy operations, so if you lose network connectivity at any point, you can just pick up where you left off.”

You can download the free tool here.

Posted by Gabriel Maciel

2 comments:

Pablo Sabbag said...

I'm wondering if copying files simultaneously will create file fragmentation on the destination storage.

jonathan reininger said...

I think your are correct...

Last night, I setup a Win7 VM and assigned it a 100G drive on my home rigs. My goal was to setup a box to dump all my photos (85G worth) on the VM and then that VM would run Moxy online back.

I setup the 100G and I kept getting an out of space error in richcopy message area in the GUI, near the end. I could not figure out WHY with nothing at all else on the D:\ drive would 85G of data NOT fit on a 100G drive. I kept doing DOS dir listings (dir *.* /s) and right clicking on the /photos dir it was always 85G..

I used the 10:10:1 threads setting a co-worked mentioned here at work. Turns out I had to defrag the drive (which was ~40%) fragmented when I copied over all the files. Perhaps the when 1 thread starts the nearby empty space/blocks/fragments were too small to fit in other 2M images into later.

Anyway, there might be some differences in the fragmentation levels on a serial tape restore, a single threaded robocopy job, and a mult-threaded richcopy job. Its going to be in your best interest to plan to save time for a defag after a data migration, especially if we use richcopy.. AND if the space we are trying to fit the data into, is very close to the capacity of the source data, we might be forced to run a defrag before all the data is moved over, just as I was force to do last night.