Write HFS+ formatted drive image to smaller capacity drive on Linux

Question

I imaged a potentially defective 1TB hard disk drive containing about 270GB worth of actual data, using ddrescue, on a Lubuntu live system. The recovery is 99.9% complete, there's only a 52KB area which was unreadable near the 300MB mark – yet there are no “pending” or “reallocated” sectors in SMART. First question : how is this possible ? Could this be a benign case of “logical” bad sectors, i.e. sectors which are physically still operational but in an inconsistent state, resulting in a CRC check failure, and could they be “fixed” durably and reliably simply by overwriting them ? I ran the short self-test, which was “completed with read failure”. Can I still trust SMART data 100% and be confident that if it reports no bad sector there indeed is none at the physical level ?

Then, I have 3 spare drives which I could use to transfer the recovered data for the owner, who uses a MacBook computer : a 320GB drive in USB2, a 500GB drive in USB3, a 1TB drive in USB3. The source drive is formatted in HFS+. Is there a safe and convenient way to write that 1TB image, which indeed occupies only about 270GB (as it was created in sparse mode using ddrescue’s -S switch), directly to a smaller capacity drive, with a Linux or Windows free tool, in such a way that the recovered HDD is readily readable, with a consistent partition table ? (I have no experience with Apple partitioning and formatting schemes.) Or would I be better off creating a HFS+ partition – with which tool since apparently GParter can't handle that – and copying the files and folders ? But in this case, would the timestamps and other metadata be automatically preserved ? Or would I have to use a specific method to make sure of it ? Can a Linux command like “cp” copy files between HFS+ partitions and preserve all attributes specific to that filesystem ?

Thanks.

Answer 1

So I did what my intuition told me : I attempted to overwrite just the tiny unreadable area with this ddrescue command (could be done with the more basic dd tool but I'm less familiar with it) :

lubuntu@lubuntu:~$ sudo ddrescue -o 312881152 -s 53248 -f /dev/zero /dev/sdb /media/lubuntu/354E48E260FCFD84/dev_zero_dev_sdb.log

[Note : the -f switch is necessary here since there is natively a protection preventing ddrescue from writing directly to a physical device.]

And it worked : as a verification, I re-imaged the first GB and this time there was no error (I had tried this partial imaging before running the above command and the error area was still there then, with the exact same location and size, I also noticed that it was skipped right away, with no slowdown, contrary to what usually happens when there's an actual “physical” bad sector and it slows down or hangs for a few seconds before skipping) ; the “short self-test” now completes with no error as well.

Before that I tried some Windows tools : a read scan with Hard Disk Sentinel made it freeze indefinitely, I had to shut down the drive ; likewise, trying to access the problematic area with WinHex made it freeze until the drive was shut down.

So, am I correct that this was a case of “logical” bad sectors, and that the drive is physically fine, and safe to use again, as there has been no “pending” or “reallocated” sector displayed in S.M.A.R.T. at no point of the process ? What is the likely cause of this, perhaps a write operation interrupted by an improper shutdown ? Is this a common issue, and does it commonly render the drive inoperant, when it affects a system file ?