0

At first, I’ll mention some background details that could help better understand the situation.

I used 1TB external drive for data storage, then installed it into Optibay to use it inside MacBook as a second drive. It was formatted as 900GB NTFS and 100GB HFSJ+ partition. It was easier to operate with HFS from macOS, so I used Paragon Hard Disk Manager to expand HFS partition to the size of 900GB and shrink NTFS to 100 GB respectively. This was done by sequential 200GB expand-shrink operations with data move from NTFS to HFS to get to the final state. From now on, HDD with this partition table worked perfectly well. SMART was OK.

But then, at some point, HDD stopped spinning, but was still identified as HDD with zero size (so, only the controller was identified, it's common for Seagate disks). A controller failure happened (the ROM was corrupted), so after fixing the ROM it was possible to make almost full RAW image of the HDD. Also, 2 heads weren’t working properly so some areas couldn’t be read. SMART C5 Unstable sector status showed BAD value, so these sectors are probably software/hardware bad blocks.
From this point I started data recovery. Two partitions were corrupted in a very strange way. I am mostly interested in HFS partition recovery, because it’s where almost all data was stored.

Of course fsck-hfs/DiskWarrior weren’t able to restore data, because the Catalog file/B-tree addressed wrong positions of the files. Volume Header was valid. I used HFS+ Rescue to view the file list. After analyzing this table I found that all file positions at this table were offset, but the offset varied from the beginning to the end of the HDD. For example, file entries 53130 – 55315 are offset 100153225216 bytes from the beginning of the HFS partition, file entries 3719 - 4446 are offset 100223311872. And it's not sequential, the offsets aren’t following the ascending order from the start to the end of the partition. Some groups are offset more, some groups are offset less from the beginning. The offset range I found was 97120280576 – 100148092928. More than 3GB difference! So I can restore these files as long as I calculate the offset of the specific file group. But then, at some point, this offset will shift so that I can no longer restore the file because I need to find the new offset.

I also found that although most file sizes and dates are correct, a significant amount of .MOV files are not full, their sizes are cut 16384 bytes before the end. Even then, with the valid header and footer, I was unable to open them as .MOV files. Other files are valid so far. And I also noticed that sometimes offset shift happens after this corrupt .MOV file (it's usually large, more than 2 GB).

So, has anyone encountered the similar problem? Is there any software that can seek and fix it? What software can you recommend to work with corrupted HFS partitions. What could possibly cause this offset shift? What could cause both partitions corruption if the catalog file/volume header is valid? And is there any available tool that could speed up the process of finding offset and recovering files if otherwise it’s not possible to recover correct file offsets?

You must log in to answer this question.

Browse other questions tagged .