I have here a partition that has a few I/O errors. I am just copying what's possible to another drive but now I want to know the files it could not read because of the I/O error so that I can restore these exact files from another source.

How can I scan the disk for files that have this error in bash?


The filesystem is NTFS and I am currently using cp to copy the files over (to a zfs disk but that doesn't matter). It takes more than a day already because it are more than 300GB and once in a while it stumbles on I/O errors and skips individual files.

The files are part of components for a DAW and single MIDI files or WAV samples are not readable. For the project files that made it through I want to reinstall the specific sample-packs from another backup but since this is really a lot, I don't want to reinstall everything or test all project files and sub folders, that might have missing or corrupt files, and waste another day or more. So knowing the path to the files that had I/O-errors, might save me some time just re-installing the few packs that got corrupted.


It depends on what kind of filesystem you have on your partition. For ext2/ext3 and ReiserFS you can find help in the Bad block HOWTO for smartmontools.

Basically, what you're doing is this:

  1. Start the selftest of the hard disk with smartctl it will tell you how long it takes.
  2. After the selftest is finished, look at the result of the selftest and recognize the first bad block. If there is no bad block, you're done.
  3. Determine the partition and the offset inside of the partition for the bad block.
  4. Using debugfs determine whether that offset is inside a file and if yes, which file.
  5. Write anything over the bad block using dd. The hard disk will replace the bad block with a spare block.
  6. Restart with 1. to get the next bad block.

You can find details in the above mentioned HOWTO.

  • @LinuxSecurityFreak I didn't know about ddrescue up to now, so I think you're probably better suited to describe how the problem could be solved with it. – Mathias Weidner Nov 5 '19 at 16:32
  • I edited the question for more clarify. Is there a way to do this automatically? Because walking through all the blocks takes longer than just installing everything from the archives. – Supertyp Nov 5 '19 at 17:11
  • @Supertyp You may use script to start a new shell and log the output of all commands. Then copy all files with cp to somewhere else - either to a fresh partition or /dev/null. At the end leave the shell and look into the file typescript for the error messages of the cp command. This should contain the names of the files with read errors. – Mathias Weidner Nov 5 '19 at 17:41
  • @MathiasWeidner I should have piped stderr to a file when starting cp, but I did not and since this is running for more than a day already, I'd like to prevent running the whole cp again. – Supertyp Nov 5 '19 at 17:45
  • When it's running more than a day, I assume that you already missed a lot of files. I don't know of any way to get the name of these other then looking at each file again. That would take the same time plus the time for the files you didn't copy until now. – Mathias Weidner Nov 5 '19 at 17:58

Let's start with your question title:

Find I/O-Errors on a harddisk

This sentence does not make any sense, the input / output errors are naturally occurring as a result of either drive wear, or in worse cases some kind of damage. Don't get me wrong, you can do for instance:

Locate bad sectors and fill them with zeros

Now your original question:

How can I scan the disk for files that have this error in bash?

is even harder to crack. Do you need a shell script (bash) solution? If so, would you explain why?

Let me get to the core of your problem (most probably):

Your hard-drive is failing to read some sectors.

Right? Because if yes, you virtually can't use cp for this task.

What can you do instead?

Start a GNU ddrescue mission (its Ubuntu package is called gddrescue, with a g!).

How do you do that, a pure example, don't twist my words, after, follows:

ddrescue -d -f -r3 /dev/disk/by-partuuid/xxxxxxxxxxxx /path/where/to/store/image/of/the/partition /path/to/log/file/of/this/rescue

You can use /dev/sdx1, of course, but it causes problems during reboots if connected more than one disk, thus simply use blkid /dev/sdx1 or whatever.

You'll be unable to identify which files are intact I'm afraid other means than actually opening the file and see / hear / whatever it should contain.

You will be able to directly mount that image without any offset, which I would normally do, but for the sake of simplicity...


  1. For the GNU ddrescue manual click me

  2. For basic information on error-correcting algorithms on data storage click me

  3. For the UUID topic in general click me

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.