WinN00b questions
 

ok - only 1 really.
As the title above suggests, this isn't my first time at the rodeo, but I'm not especially well versed in low level OS X foibles.

I'm trying to pull data off a formerly bootable, currently mountable drive in a MBP.

I could care less if its a simple file copy or an image, but where I have failed with ALL utils so far is when I come to an unreadable file.

What I suspect is that the user completely filled the drive, the OS puked, and we were left with a lot of partially written files.

Add to this the attempt by the Genius Bar folk to do an archive/install on a clearly full drive...

Having said that, my impression is that the drive is 99.99% intact.

The game plan is simply to back up the data, nuke and repave, and restore the data.

I'd prefer not to have to manually select all the files, but without knowing which are corrupt in advance, deleting them before copying isn't a feasible option (and a bad approach anyway.)

[Star Wars Analogy Warning]
What I would like to find is a Jedi Mind Trick setting, where when the app encounters a file it can't read, it's told "this is not a file you need to copy, there is nothing to do here, move along," and simply log the exception, rather than throwing it's hands in the air and giving up.
[/Star Wars Analogy Warning]

Am I missing such an obvious option?

I realize the goal of imaging software is to create a pristine replica, but that isn't always possible or required. And I really don't want to drag out my data recovery apps which do have these options, since the damaged files don't need to be recovered, and the undamaged ones obviously don't need this either.

We're not designed to copy damaged drives. Sorry!

I understand, though I respectfully submit that you may want to revisit this in a future version.

I'm not suggesting that you become a data recovery applet, but bad blocks are something that happens to 100% of drives *eventually*

Automatically failing on any drive with any unreadable data doesn't seem to me to be a great strategy.

It falls in line with Apple's approach though, so I understand this.
It's unfortunate that OS X also has no provision for bad blocks either.
It does help me understand why frequent backups are more common in the Mac world.

I thought you all were just paranoid, but you're just dealing with a lack of functionality.

I really don't want to digress into an OS Holy War - but I would point out that Apple's failure to make provisions for bad blocks is NOT normal and I know of no other platform that lacks the ability to detect and mark them, most also have the ability to move the data to a safe location.

I had to use a third party utility to even expose the bad blocks on this drive.

How OSX deals with this is kind of beyond the scope of this discussion, and not really relevant. But, regardless, I discuss this particular design decision in this blog post.