0

Apologies for the title. To be more specific, I recall reading this somewhere in the last year when I was trying to repair data damage to a hard drive.

I have a windows XP hard drive that suffered a head crash and caused unrecoverable bad sectors on certain files. I'm cloning the drive to a duplicate drive and replacing the files that were damaged using a backup I had from long ago.

What I've done already is... I booted into Parted Magic from the Ultimate Boot CD and used linux's ddrescue tools to clone the damaged drive into a disk image, then used the logfile.txt to write DEADBEEF to all sectors it couldn't read/clone to the disk image file and make a complete image. I then used one of the linux grep commands, I believe, to try to search the entire file system for the string DEADBEEF and list all files containing that string, though had some trouble with it quitting hours into the search due to some odd error.

I also manually repaired the $MFT's (Master File Table) errors, everything except a single picture file's data which is unimportant, so that I could scan the entire file system properly and see all files (some were not showing due to the damage).

What I need to do is this:

I want to fully scan the entire drive down to the byte level (as if looking at the disk image in a hex editor), every sector, for the string DEADBEEF, then have it list every file that the bad sector overwritten with DEADBEEF belongs to according to the filesystem. I remember reading about this somewhere, being able to scan the drive and once it finds the string, it lists the offset/location/sector of the DEADBEEF string and what file owns the data in that sector. That, or every bad sector and lists what file the bad sector belongs to.

The ddrescue logfile lists every sector that was detected as unreadable (about 1000 200-byte sectors), where it wrote DEADBEEF to. If I know what files own those bad sectors, I can replace them using my old backup.

Before you ask, I can't just use the old backup alone because it's about 3 years old. The old backup is actually the original drive from this computer, which I cloned to this drive that I'm trying to rescue. Most of the bad sectors from the hard drive crash were in a part of the drive which only had files that were present from the original drive. I can easily copy those files from the original to the new drive to fix all the DEADBEEF bad sectors, but I need to know what every file is that those bad sectors belong to.

Again, I recall reading something about scanning all sectors of a drive and having it list any file that a certain sector belonged to. So how do I do this from Parted Magic? I have to mount it in there so it is mounted as read only.

closed as off-topic by mikewhatever, karel, Elder Geek, Andrea Lazzarotto, Eric Carvalho Apr 15 '17 at 11:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This is not about Ubuntu. Questions about other Linux distributions can be asked on Unix & Linux, those about Windows on Super User, those about Apple products on Ask Different and generic programming questions on Stack Overflow." – mikewhatever, karel, Elder Geek, Andrea Lazzarotto, Eric Carvalho
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Parted Magic is not Ubuntu therefore off-topic here. And you should have stopped using XP years ago. – user589808 Apr 14 '17 at 4:24
  • Look, I don't know where to ask this, but Ubuntu is linux and parted magic is linux. The info I'm asking about can be done in both from the command line, that's all I know. My question isn't about whether I should or shouldn't have XP. This is an old computer and all I can afford and has all my important programs and data with a lot of suspended sessions I want to have restored. It's easily possible if I get the damaged files replaced. – DCX Apr 14 '17 at 4:35
  • 1
    @CelticWarrior "the help you need is not technical, is the help provided by mental health professionals" ... seriously? That's pretty rude. There are legitimate reasons to want to recover data from an old XP drive, and even boot XP - maybe some old programs holding important data won't run on anything newer. But honestly nothing about XP is even relevant to the question - just "fat or ntfs" – Xen2050 Apr 14 '17 at 7:41
  • @DCX I think you may be doing this a hard way - if you can read most of the files on the image, and you've got the old backup readable too, then just compare their files (I'd use kdiff3 or another GUI folder diff program) and copy over whatever's missing or different, unless you know it's a newer data file you want to keep, or you search it for "DEADBEEF". Actually, mounting the image & searching all files for "DEADBEEF" would be much easier, I can almost see a find...grep command doing that now, it doesn't matter if free space was "corrupted" anyway – Xen2050 Apr 14 '17 at 7:46
  • Since you already have the list of bad sectors from ddrescue, isn't what you really want to know How to find out what file is on a particular sector? The sourceforge page for ddrutility says it can "Find what files are related to the bad sectors using a ddrescue logfile". – steeldriver Apr 14 '17 at 12:24
1

You could do like the helpful comment from steeldriver says and use ddrutility

It doesn't appear to be in the Ubuntu repos, but it's home page is https://sourceforge.net/projects/ddrutility/
Specifically use it's tool ddru_findbad
Here's a clip from it's wiki page:

ddru_findbad
It is a bash script that will try to find which files are related to bad sectors in a ddrescue log file.
It relies on 3rd party utilities for its functions. It may not work on all systems. It can be slow, and can be very slow if not unusable if there are a lot of bad sectors in the list (it does not work well with a large error size).


I'm tempted to forget about sector numbers and just mount the cloned image & search all files for "DEADBEEF", with find, xargs & grep in a Ubuntu (or Xubuntu, Lubuntu, or Debian, most any Linux).

Whether it's easier or faster than trying ddru_findbad or not probably depends on how big & fast your disk image is.

find /mnt/x -type f -print0 | xargs -0 grep --files-with-matches "DEADBEEF" >> list

Where the image is mounted to /mnt/x. Then the file list has all the filenames that match. Any free space that has DEADBEEF are ignored.

  • I'll try that. Last time I was working on this, I got help from someone that had me try this: [[ "for i in find . -type d -maxdepth 3; do echo "Looking in $i..."; grep -r -l DEADBEEFDEADBEEF "$i" 2>&1; echo "done with $i"; echo ""; done | tee greplog.txt" ]] ...but it failed telling me "find: paths must precede expression: 3" ..... There are 2 ` in that code before find and after maxdepth 3. (how do I make this properly line break, it isn't working) – DCX Apr 15 '17 at 18:06
  • Yeah, that code you tried appears to be parsing find's output too, which would probably fail on names with newlines & maybe even spaces - find's -print0 and xargs -0 takes care of that, and also makes looping unnecessary. Would you really want a message saying what file's being searched anyway, and when done? Could be 50,000+ useless messages, and I think grep can output filenames with non-matches too. Actually grep's -r reads recursively under the directory too, so that could've been searching folders 3 times. And all in a test? Writing to the damaged fs? Weird, don't do all that ;-) – Xen2050 Apr 15 '17 at 19:36
  • I can't quite remember why it was set up that way, but I remember wanting to see it tell me what was currently being searched so I could tell if it was stil running or not. I think the last times I tried, it was frozen for 10 hours overnight and I didn't even know it stopped working since there was no line indicating it. I think I also wanted that to see when it hit a problem file, as there were 2 files it was mysteriously failing on, no reason I could find, but very annoying after trying to do the original search for 2-3 hours every time. Looks like ddrutility does exactly what I need, too. – DCX Apr 16 '17 at 0:50
  • Now that I think about it, it might have been so that it would not quit searching if it hit a problem file. As I said, it was extremely annoying doing the search for 2-3 hours, then having it quit, unfinished, for some unknown reason talking about the file it had a problem with and I was left without knowing what files and directories it had already scanned for DEADBEEF. I don't want to just delete the files, either. From what I could tell, there was no actual problem with them at all. I looked through them in a hex editor, no bad sectors or anything, & I could copy and read the file fine. – DCX Apr 16 '17 at 0:53
  • I see. I'd use a system monitor to see if there was any disk reads going on instead, but that wouldn't say what was being searched, some type of logging would help there, but with filename spaces & crazy stuff like newlines allowed parsing file lists can be tricky. That wasn't on the damaged drive itself right? The good copied info shouldn't have any read errors (after fsck), and trying to search a failing drive isn't likely to make it any healthier (more like to fail with each read). – Xen2050 Apr 16 '17 at 1:13

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