hfsprescue, getting negative value for offset

[roundjr]

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 https://www.plop.at/de/hfsprescue/partition_offset.html 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:

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

Then:
$ 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.)

[Elmar]

Are you sure that you had a block size of 8192 bytes and not 4096?

[roundjr]

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.