Author Topic: hfsprescue, getting negative value for offset  (Read 1122 times)


  • Newbie
  • *
  • Posts: 2
hfsprescue, getting negative value for offset
« on: May 23, 2017, 20:54:23 PM »
I am probably misunderstanding something, so I'll try a question here:

I have an accidentally formatted external USB-drive (3TB).
I have run ./hfsprescue -s1 and -s2, filenames have been found, but attempting a restore with -s3 produces garbage files, so I assume I need an offset value for the restore. I have not been able to get that to work.

I am using hfsprescue 3.3 2017/03/3 on macOS 10.12.5

I have tried finding the partition offset using the procedure at with two different reference files, and both file patterns have been found, but don't think I am able to interpret or use the results correctly. Both files give the same negative number as the result:

For one file I get the following:

$ ./hfsprescue --list | grep DSCN1749_rotation.JPG
13245: DSCN1749_rotation.JPG, 1212395 bytes, 1099222886, Sun Oct 31 12:41:26 2004, Start block 4821307

$ sudo ./hfsprescue --find /dev/disk6s2 -ff 8192 DSCN1749_rotation.JPG
File DSCN1749_rotation.JPG: Bytes found at offset 39390806016 + 483328 = 39391289344 (0x92be00000 + 0x76000 = 0x92be76000)

But using the formula (offset = byte_search_result - list_start_block * block_size) I get a negative value:
39391289344 - 4821307 * 8192 = -104857600

I assume that is not correct? If someone can shed some light on it it would be greatly appreciated.

(If I manage to understand what is going on here, I also seem to have an issue with getting --one-file and the offset switch -o to work at all, but I will get back to that if I manage to calculate the offset correctly.)


  • Administrator
  • Hero Member
  • *****
  • Posts: 2405
  • a command shell is enough to do amazing things
Re: hfsprescue, getting negative value for offset
« Reply #1 on: May 24, 2017, 08:35:53 AM »
Are you sure that you had a block size of 8192 bytes and not 4096?


  • Newbie
  • *
  • Posts: 2
Re: hfsprescue, getting negative value for offset
« Reply #2 on: May 24, 2017, 09:14:14 AM »
Thank you very much!

I assumed 8192 for my 3TB drive, but it appears 4096 is correct, as I did manage to get a partial restore of the file when calculating and specifying a block size of 4096 just now. I did try this earlier with no luck, so must have made a mistake in my calculation or command line.

As the file appears to be fragmented, I guess I will make some attempts at getting the Extents Overflow File from the formatted drive.