Quickest Way To Move 160GB?

H2SO4 said:

...Every scenario calls for a particular range of attributes:

- Is it multi-threaded? Multiple concurrent copy operations are A Good Thing.
- What's the "chunk" size? Different sizes produce different effects. Bigger is not always better.
- How granular is the control over what to copy?
- Logging? How verbose?
- Scriptable? Easily?
- Robust - can it recover from unanticipated transients or at least report them?
... and so on.

...

For outright speed: ROBOCOPY <source> <dest> *.* /E /MT:8

I am interested in your analysis of Roadkil's Unstoppable Copier.

Kind words, indeed.

Actually, I use RoadKil UC during a system recovery only. It is my shotgun for grabbing files off of a failing HDD or failed/failing OS install.

I know there are more elegant methods, but I am all about time on task.

Here, I am probing The Acidic One for in-depth knowledge. When his cookies crumble, the floor gains IQ.

These utilities are all just front-ends for one or the other of the in-built file copy mechanisms. Every scenario calls for a particular range of attributes:

- Is it multi-threaded? Multiple concurrent copy operations are A Good Thing.
- What's the "chunk" size? Different sizes produce different effects. Bigger is not always better.
- How granular is the control over what to copy?
- Logging? How verbose?
- Scriptable? Easily?
- Robust - can it recover from unanticipated transients or at least report them?
... and so on.

None of these utilities implement some magically new method, but the multi-threaded ones (robocopy, richcopy) will have the performance edge, everything else being equal. Robocopy is highly configurable and scriptable. Richcopy is simpler and easier to use.

Cut'n'paste is the one method which should be avoided for massive transfers. It relies on the clipboard and that introduces extra complexity which cannot hope to match the throughput of the other mechanisms. The copy/xcopy commands are somewhere in between - devoid of the shell "chattiness" overhead inherent in drag'n'drop and cut'n'paste, but single-threaded and therefore not as fast in many cases.

For outright speed: ROBOCOPY <source> <dest> *.* /E /MT:8

It seems clear that robocopy is your favourite for this one. I knew that cut'n'paste should be avoided (i've got stung before!)
All i need, is to move 160GB of data (including empty folders) from my internal drive to my external drive as quickly and reliably as possible with errors/missed files/failures being reported along the way or at the end. It's no problem for the move to consume my entire PC for the duration either.

Bob, correct me here if Im wrong, but TAR isnt a windows file ... its Linux...

I don't think you're wrong , i've been having a bit of a fling with Ubuntu Karmic recently and i've come across alot of TAR files. I've never seen them in a Windows environment before.

Bob, correct me here if Im wrong, but TAR isnt a windows file ... its Linux...

I think you can open tar files if you have winrar or 7zip. They're multi-platform I believe.

Antman said:

I am interested in your analysis of Roadkil's Unstoppable Copier.

I've never used it, so please keep that in mind when gauging the value of my opinion :)

From looking at the description and screenshots on the Roadkil website, I think the utility's primary trick is to ignore or bypass the NTFS "bad cluster" designation, and then presumably do some statistical analysis of a given cluster's contents. Say we read a byte 10 times. The results are 7 times 'A', two 'H's, and a lone 'X'. We'll conclude the most likely original datum was an 'A' and cross our fingers. The value of such a recovery will depend on the data type's tolerance for anomalies, and admirably he points that out in the tool's description.

I'm curious about the mechanism used to bypass the NTFS $BadClus metadata. It's doable with a driver, but that would imply a degree of sophistication greater than many of the other utilities on the site. Perhaps there are user-mode APIs to query that info without a driver? I don't know.

Either way, the tool's recovery abilities are presumably dependent on first running a full CHKDSK /R so that bad sectors are identified and tagged (in $BadClus). Otherwise, there'd be no way to tell good sectors from bad short of first duplicating CHKDSK sector verification code (which is not conceptually complex), or subjecting every single cluster to the same statistical results analysis - a prohibitively time-consuming strategy which could take many days on large volumes.

===============================

The dropdown list of minor European languages blankets most of the "Settings" tab screenshot, but there seems to be no overt mention of multi-threadedness or other copy throughput enhancements; emphasis seems placed squarely on the recovery aspect of the utility. Hence, my guess is that it wouldn't compete favourably with tools built for speed, and it may not be the best solution in the OP's scenario.

rsvr85 said:

I don't think you're wrong , i've been having a bit of a fling with Ubuntu Karmic recently and i've come across alot of TAR files. I've never seen them in a Windows environment before.

Without in any way wishing to play down others' suggestions, I don't believe file compression or "cabification" is going to make any difference in your scenario (two local drives). In fact, it would take (far) longer to first compress 160GB into a tight ball, then copy, then decompress on the target drive. That strategy is valid under certain circumstances - very slow network links for example - but the "bandwidth" of the underlying hardware between the source and destination is not the primary bottleneck in this instance. Instead, what's important is the way your chosen copy tool breaks up data into segments and invokes OS functionality to copy it across.

Strollin is right USB2 or Firewire 400 is the weakest link for sure. Any copy method you choose can keep them saturated.

Without in any way wishing to play down others' suggestions, I don't believe file compression or "cabification" is going to make any difference in your scenario (two local drives). In fact, it would take (far) longer to first compress 160GB into a tight ball, then copy, then decompress on the target drive. That strategy is valid under certain circumstances - very slow network links for example - but the "bandwidth" of the underlying hardware between the source and destination is not the primary bottleneck in this instance. Instead, what's important is the way your chosen copy tool breaks up data into segments and invokes OS functionality to copy it across.

I agree, avoid compression. It will take long to compress and uncompress than it would to just move them.

H2SO4 said:

Antman said:

I am interested in your analysis of Roadkil's Unstoppable Copier.

I've never used it, so please keep that in mind when gauging the value of my opinion ...it may not be the best solution in the OP's scenario.

All that and a bag of chips. It can be a bit time consuming to run. I use it even in situations where I do not expect disc damage. Like other utils, it does not stop when it encounters a locked file.

I have to admit - it is a tool I have been using for years, and since it has never failed me (to my knowledge), I just keep using it.

I have to give you some props - I learn something every time you click submit.