It's hard to know what could be done here: the difference between what we're doing and what's "working" (in Finder, for example), is that Finder and Synchronize Pro are going to be using Carbon file calls (native to HFS+).
We're using Cocoa calls, which operate with the Unix paths (as does ditto, which is also generating an error). Speaking out of relative ignorance of the HFS+ file system drivers, there might be a wacky mis-mapping between the two layers which is causing a problem. That could explain why Finder can sometimes copy a file that SuperDuper! can't, too.
I don't understand, though, how Finder and Sync Pro can copy the drive if the data's corrupted. They're not copying the drive: they're
partially copying the drive, I believe -- no?
This might be a situation where rebuilding the HFS+ catalog would help, or at least be worth a shot. There's a paper about it at the Coriolis Systems site:
http://www.coriolis-systems.com/manu...logRebuild.pdf
(I may have mentioned this to you before.)