New to the forum. I have a file to restore that's fragmented into 36 chunks. I've read a lot of NTFS documentation and I understand it. What I haven't been able to find is the meaning of a zero offset byte when it's the last in the block. Anyone know the meaning?

32 02 04 63 A3 00 32 B8 03 7D 76 FF ...

Decoding this with my limited understanding:
2 length bytes and 3 offset bytes in the first block.
length = 0402 = 516 clusters @ offset 00A363 = (41,827 * sectors_per_cluster) + partition first sector

This is the right location for the first block but decoded this way puts the next block impossibly negative. The 6th byte in the string obviously means something I do not understand. Anyone?

Note to self: DOH!

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

run 1. 32 02 04 63 A3 00

Length = 0x0402
Offset = 0x00A363

run 2. 32 B8 03 7D 76 FF

Length = 0x03B8
Offset = 0x10019E0 (0xFF767D relative to 0x00A363)

No? (Been a while)

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Wait, I see the problem, can you post entire file entry?

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Did you take update sequence array into account?

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Similar thread ...

https://forum.hddguru.com/viewtopic.php?f=1&t=28987

_________________
A backup a day keeps DR away.

Nice. I'd still like to see the entire file record. if you get weird values, there's a chance your data run 'uses' last two bytes of first sector of the file record in which case you'll have to look up actual values in the update sequence array. So, in these cases it's good to see the entire record. it must be well over 10 years since I wrote software to recover files from NTFS but I clearly remember that kept me frustrated for days (yeah, I'm not that much of a programmer).

_________________
Joep - http://www.disktuna.com - video & photo repair & recovery service

Arch. Thanks for the response...s. Yes on the update sequence, last two bytes in the sector. It doesn't pose a problem when I properly promote 3-byte 5-byte 6-byte and 7-byte integers to a uint64_t. Seems like a wasted byte in a data run and hadn't seen it before. I recovered the file this afternoon.

I'm brand new to the C language. I skipped the "Hello World" program and went straight to "Hmm. Let's see if I can completely rebuild a Windows drive that's been formatted". Well, I can. Got it working this afternoon, after 8 months of free time at the keyboard, internet and "C by Example". Have to add some code for sparse and compressed files and clean up the code a bit what the heck, I can finish it without reading anymore.

Thanks again.

The complete datarun

32 02 04 63 A3 00 32 B8 03 7D 76 FF 22 93 03 C5 F8 22 5A 03 A7 ED 22 B8 02 13 33 22 A8 02 D7 09
32 8D 02 BC B6 00 32 82 02 E9 15 FF 22 FC 01 6A 3B 22 97 01 62 F3 22 58 01 21 37 22 3D 01 80 59
32 2F 01 17 46 FF 32 24 01 E2 DA 00 22 F0 00 AB FA 32 AA 00 5C 29 FF 22 A0 00 C7 F7 22 91 00 3B
1F 22 83 00 E7 53 21 79 01 06 21 79 AD 8D 31 63 D9 D0 00 31 4E 3A 42 FF 21 3C C7 E3 31 28 BB EF
00 21 25 1D E5 21 25 55 A2 21 24 F6 68 31 20 64 20 FF 21 13 AD 03 31 0B BA E5 00 21 07 F2 D7 31
01 6A 3A FF 22 62 02 A0 4B 22 9B 01 07 05 22 E9 00 70 12

Amazing!

Nice work.

_________________
A backup a day keeps DR away.

... as i thought, a zero there does not mean it is wrong...
But then what did you need to fix from a C program?

pepe

_________________
Adatmentés - Data recovery

Im guessing by the first post it is throwing all the chunks back together.

pepe

In my program I needed to take a variable number of bytes (1 to 8 bytes) and use them as a signed offset to the next chunk of data to rebuild the file. Not being familiar with C, I was doing it wrong. I put the first byte into an int64_t variable and shifted it left 8 bits then added the next byte. When all bytes were in the int64_t I NOTed it and added one. It gave me a negative number but not the correct one. I still don't know why it wasn't correct.

What did work was simply to OR the variable with all unused upper bits with 1.

HaQue

Correct

Thanks guys.

This sounds like it could be to do with 2's complement, I remember from University years ago but programming since I have never really had to worry about it, the int/float etc declarations are enough for anything I have needed to do as I never pursued software engineering after the degree.

https://www.cs.cornell.edu/~tomf/notes/cps104/twoscomp.html

HaQue

Yes 2's compliment stuff.
I didn't know how to correctly take individual bytes and put them into a signed 64-bit integer. I should have posted in a C programming forum but I thought the problem was in my lack of understanding of the data run. Found my answer. Thanks.

Update:

That 0x00 does mean something. After doing a bunch of testing with fragmented files, I believe that "If the last byte in the offset is 0x00 AND the next to last byte is greater than 0x7F then you should interpret the offset as a positive rather than a negative value. This project has been quite the challenge for this novice.

yeah, of course, coz in that case the sign bit is clear.
good point.
pepe

_________________
Adatmentés - Data recovery