Robust Copy, errors during virgin copy

[bawldiggle]

As a "Robust Copy" virgin while copying 70 GB of files to a new partitioned ext. HDD I was swamped with several "xplorer2 alerts'
- swamped might be an overstatement but for a first timer the alerts have shattered my faith ...
- [x] Use queue ... enabled
- this is just some of the alerts before I stopped copying ...

Assembled x4.png

... I abandoned "Robust Copy" and considered Win Explorer (ClassicShell) Classic Explorer.

Of three original AVI files (they all play in VLC) but only file1.avi and file2.avi have copied to the new HDD but no sign of file3.avi
file1.avi -- 28.9MB
file2.avi -- 36.6MB
file3.avi -- 28.9MB << did not copy

With 70 GB of files (incl 4,500 txt files) manually checking is not an option
- just discovered "Options" for "Robust Copy" ... to record errors to a log file (when all else fails, read the directions)

What might have gone wrong ?
- would my heath-Robinson connections + USB 2 be a problem
Ultimately I want to abandon the pocket HDD (all my data) and use the mains powered HDD ... hence the "copy" exercise.

Would appreciate any advice
-------------------
SPECS:
Toshiba laptop (Satellite C665) -- USB2 only
Win7 Home Premium 32 bit
Classic Start + Classic Explorer
Kaspersky Internet Security 2015:- no alerts during copy
Source HDD: pocket HDD/spinner (Imation M100) USB2 (NTFS)-- self powered -> connected to mains powered hub

• - Two days ago I disabled drive property "Allow files on this drive to have contents indexed in addition to file properties"
  - since then I discovered Windows does not index external drives anyway
  

Hub:= mains powered 5v 3amps -> connected to Toshiba laptop
Target HDD: (new) 500GB, WD Blue 500GB mains powered HDD (NTFS) -- USB3 -- connected directly to USB port on Toshiba

[nikos]

that looks like a hardware or connection problem. Try the copy again? If you suspect that robust copy is to blame then use normal drag/drop or copy/paste and see what happens

[Kilmatead]

I can't claim to be a hardware expert, but like most members of this forum I have nursed more than my fair share of recalcitrant USB drives through their last days of palliative care.

As self-powered portable drives tend to have a latency that would make a grandmother blush, don't try to copy everything at once - select only portions of the tree and see if it's more successful (potentially the controller is probably geared for USB3 and its error-response might not be downgrading properly).

If possible, do not use the "hub" at all when transferring between drives - instead just connect the old drive directly into your computer (no hub), transfer a portion of the total, and then disconnect the old drive and transfer from the computer to the new drive (again, no hub). Rinse and repeat. This removes another layer of abstraction and potential problems (even high-end USB hubs are not the most reliable things in the world).

Disable other things (such as antivirus) which monitor disc-access as when they sense a change to the drive, they often jump in to check it before the handoff and all that extra attention (it probably spins at painfully slow rate with insufficient buffering in the first place) just overloads the poor R/W head, causing the latency hiccup, and thus errors are returned.

As Nikos says, try drag-n-drop (that will use Windows built-in copy which doesn't do as much integrity checking), so there's less overall stress on the drive for any sustained period of time.

As a last thought, I don't put much stock in user-reviews as a going concern, but I did get a disparaging chuckle out of these as a quick search.

[FrizzleFry]

I have seen those errors when the full path name is too long.
How long is too long? I'm not sure.

[nikos]

how long is a piece of string?
long pathnames are those above 260 characters, but these error messages don't look that long

[Kilmatead]

Robust Copy/Move works with paths greater than MAXPATH anyway, so it shouldn't be an issue here. Windows Copy/Move, however, does not handle MAXPATH well, so drag-n-drop would indeed fail, but it would at least report the appropriate error message relating to path-lengths, and then fail spectacularly to compensate for it properly.

[FrizzleFry]

I've had robust copy (F5) fail with some long paths but I was able to robust copy to shorter paths and move to the desired path... so it seems the failure comes when trying to create long paths... if I remember correctly, these failures happened when copying from one drive to another...

[Kilmatead]

Having spent half-an-hour earlier annoying Nikos with emails pertaining to a test I was doing which involved copying/moving (cross-volume) folders with (intentionally created) 550+ characters in their paths, I can safely say that Robust Copy/Move does not have a problem with these paths.

Nikos explained (when I queried an anomaly) that when x2 encounters a greater-than-MAXPATH path, it converts all the contained subfolder nodes into 8.3 format, which then shortens the fullpath immensely, and subsequently mitigates reliability problems (technically, from that standpoint, one would require a folder-depth of 24 levels [plus extended names] to breach even the Win32 API's MAXPATH limit).

Granted, all sorts of evil things can happen when trying to create or pass these paths to third-parties, but within the aegis of x2 (i.e., "Robust stuff"), I can't seem to derail it. (That said, if I were a betting man, and if I had a [for example] network-connection to bet with, one could probably find a way to smuggle the tea out of China and die horribly for one's trouble. But on normal drives, all seems demonstrably "robust" enough to me. )