1

I am trying to copy an old drive onto something newer so I can more easily access files, but the problem is a considerable portion of the files result in CRC errors, this wouldn't be a problem if I could just ignore that and get as many files on my newer drive as possible, but there seems to be no way to completely ignore errors.

Each error causes the copy process to stall for about 20 minutes before continuing, and I estimate there should be around 10,000 "bad" files on the drive (I do not want to risk an error happening any time in the over 3000 hours that would take) so is there a way to completely ignore errors and not even check for them?

I used the /c argument in the copy command, but that just tells the process to continue after it encounters an error, it does not ignore errors. I am running Windows 10.

I have now considered robocopy and determined it does not have the desired features (ignoring errors completely) Its even slower than xcopy (what I was using before). Unless there is some undocumented feature in robocopy to actually ignore errors, this is not what I am looking for.

I have again confirmed that robocopy IS NOT WHAT I AM LOOKING FOR, it does not have any clear functionality to NOT CHECK FOR ERRORS.

I do not want to check for errors, then skip if detected I want it to copy the exact file, as it is, and thats it, no checks at all.

Nifle
  • 34,203
  • 26
  • 108
  • 137
Vidgame Doksha
  • 11
  • 2
  • 1
    Please indicate what OS and command you are using to copy files and perhaps someone in the community will be able to provide some recommendation. – Darius Jun 13 '22 at 02:30
  • Sorry, added the windows 10 tag now. – Vidgame Doksha Jun 13 '22 at 02:34
  • 2
    You need robocopy. It does what you want. I've marked this a duplicate of a robocopy question about recovering from a faulty drive, which is essentially the same scenario as you. – music2myear Jun 13 '22 at 03:48
  • Robocopy still has the issue of taking multiple minutes per error, in addition, it takes much longer than my previous method, so its completely useless. – Vidgame Doksha Jun 13 '22 at 12:17
  • @VidgameDoksha [`RoboCopy`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy) is the correct program to use for this, with parameters `/R:0 /W:0` _(default retries is 1M)_ – JW0914 Jun 13 '22 at 14:19
  • @JW0914 I dont want it to try to check for errors at all, I already did what you said (/r:0 /w:0) that doesnt help because when an error occurs it still tries to verify that an error has occured (r:0 means it doesnt *retry* checking for errors, I dont want it to check for errors in he first place), why it takes so long I do not know, but I simply want to copy over files as they are read from the drive, without any checks for errors at all. – Vidgame Doksha Jun 13 '22 at 17:59
  • @VidgameDoksha It would help for clarity if you post the output of what's occurring with `/r:0 /w:0` - how much time is it taking per file with an error when using the latter? – JW0914 Jun 13 '22 at 18:30
  • @JW0914 I really dont want to run it again, from memory the last time I tried without /r:0 it took a 600mb file about 20 minutes to throw an error (Cyclic redundancy check error, cant remember the exact message). It also took around the same amount of time for a 4mb file, so the issue isnt with size. the error is always the same. – Vidgame Doksha Jun 13 '22 at 19:48
  • I have found that the best method is just use Roadkil's unstoppable copier, its slower in copy speed, but it actually handles errors well so its much faster than robocopy or xcopy – Vidgame Doksha Jun 14 '22 at 19:02
  • I would like to edit my previous comment to say that although its "better" its still fucking shit, but apparently you can only edit superuser comments on mac – Vidgame Doksha Jun 15 '22 at 00:23
  • @VidgameDoksha Regarding your edit request: It is unclear what errors are you talking about. Errors on hardware level (e.g. by HDD) can not changed by software. If an HDD takes 1 minute to read a defect block then you have to wait so long. – Robert Jul 10 '22 at 10:29

0 Answers0