Copy single file with I/O errors

copy/pasteerrorhard drivehddntfs

I would like to copy a file from one disk (HDD with filesystem NTFS) to another (SSD with ExFAT, if it matters).
The problem occurs in the middle of the copy process, showing me the following message:

The Finder can't complete the operation because some data in "File.data" can't be read or written. (Error code -36)

I have tried to use cp, rsync and dd without any luck.

The rsync command (with --ignore-errors flag) throws me the following error:

rsync: read errors mapping "/Volumes/HDD/File.data": Input/output error (5)
rsync: read errors mapping "/Volumes/HDD/File.data": Input/output error (5)
ERROR: File.data failed verification -- update discarded.
rsync error: some files could not be transferred (code 23) at /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-51/rsync/main.c(996) [sender=2.6.9]

dd just copied a partial data (the part before the problematic sector, without skipping it).

Any ideas how to copy this damn file?

Best Answer

Aside from dd there is also ddrescue although it's not a native OS X/macOS utility, however it can be installed in a number of ways. Personally I prefer to compile directly from source code however Package Managers like Homebrew can be used, or a precompiled binary if one is comfortable accepting a precompiled binary from an non-authoritative source.

Note that to compile from source code or use a package manager you need to have Command Line Tools for Xcode installed. You do not need to have the full Xcode installed, just the Command Line Developer Tools which are only a couple hundred megabyte vs many gigabytes.

The Command Line Tools for Xcode install can be started from Terminal with the following command:

xcode-select --install

To use ddrescue read its manual page, man ddrescue in Terminal, or online: GNU ddrescue Manual

Error code -36

-36 (ioErr) (I/O error) is a file system error, it indicates that data cannot be sent or received by the operating system. Historically, errors of this type were bummers.

Finder: source and destination

Think not only of the source (the CD); think also of the destination.

The file

What is the one file that Finder can not copy?

The file system

What type of file system is the destination? The answer will be amongst results to the following command:

mount

A volume with file system type hfs should be good for most purposes.

Depending on what you wish to copy, other types of file system may be equally good.

Disk Utility

For copying a CD in its entirety – or for imaging a file system within a CD – Disk Utility is ideal.

MacOS – How to identify and fix files with corrupted / inaccessible disk blocks

If you are facing a healthy file system at the level of its structure and want to find files which have disk faulty blocks, here is how I would proceed:

Make a full backup of your disk with Time Machine or Carbon Copy Cloner

Check this backup.
Run the following heavy and risky (in case you do have bad blocks outside of your filesystem structure) command (make sure the {} is quoted so filenames containing spaces work):
```
find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
```

This heavy find command will print for any plain file its name (thus not reading it, but just its directory entry) and then continue making a full and fast read of all its data blocks.

Upon hiting the first file containing bad blocks, this find will cause the kernel to log read error on /var/log/system.log, and it will either slow down or bring your system to a total halt. This will mostly depend on the hard drive capacity to relocate the bad blocks found on its internal pool dedicated to this usual fix task. This file containing bad blocks will be the last name printed by find.

Write down this file name on a piece of paper! Let's say that this file name is:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

At this point you may have the possibility to kill find quickly by hiting ctrl+C. If killing it nicely is failing, just crash your Mac.

Upon rebooting your Mac, directly check the file containing bad blocks:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

If the command terminate correctly, then the error was light enough for your disk to be able to read this file and reallocate the bad blocks.

If the command doesn't terminate, you won't be able to kill it normally, your data is totally lost, and you will have to crash your Mac once more.

In this last case, you have to consider replacing your disk and to work from your last backups. Some other files might also contain bad blocks and may have stayed undetected since a long time as long as you didn't read them.

The kernel won't fire a read error on a block you never read.