Let's see if we can clear the "math" aspects.
The partition table in the MBR says that you have two partitions.
#0 07 00 0 32 33 12 223 19 2048 204800
#1 07 80 12 223 20 1023 254 63 206848 976564224
The above data is expressed in sectors (i.e. you multiply them by 512 to have bytes).
So you have:
2,048 "unused" sectors
204,800 sectors used by first partition
976,564,224 sectors used by second partition
2,048+204,800+976,564,224=976,771,072 sectors x 512 = 500,106,788,864 bytes <-this is the theoretical size of the whole disk (and of the image)
Addresses in the MBR are expressed in sectors and relative to the beginning of the disk.
Addresses in the PBR or bootsector are expressed in clusters and relative to the beginning of Volume (in your case, like in, say, 99.99% of cases, your filesystesm uses clusters 4,096 bytes in size). This means that a cluster is 8 sectors.
On your volume "range of size" the NTFS by default will place the $MFT at cluster #786,432.
786,432 x 8 = sector #6,291,456 but since the volume starts @ (2,048+204,800)=206,848 when you access the whole disk or the image, it will be on sector (206,848+6,291,456)=6,498,304
Still by default, the $MFT Mirror is placed at 1/2 (one half) of the Volume.
So - seemingly- @ 976,564,224/2=488,282,112 which corresponds, when you open the whole disk or image to 206,848+488,282,112=488,488,960
But the above is "wrong", because there are two things I omitted:
- since it is an address inside the volume, it has to be accessed in clusters
- there is always one sector after the volume but inside the space reserved for it dedicated to the backup of the bootsector
In reality, the volume can be at the most 976,564,224-1
= 976,564,223 sectors, which, in clusters means 976,564,223/8=122,070,527.9
So, if you do 122,070,527/2=cluster 61,035,263,5
, and in bytes 61,035,263 x 8 = 488,282,104 bytes.
Consequently the %MFT mirror should be @ 206,848+488,282,104=488,488,952, or, more simply, one cluster before what you would expect by doing the simplified calculation.
I hope the above explains it all
I'll check the new file extracted and let you know.
Edit: quickly checked, I now see where the problem is
You are continuing to "mix" between the "sectors" and "bytes" fields of the datarescuedd tool.
I asked you the SAME
range you had already posted that in bytes
was (the datarescuedd uses bytes
[3326976000-3332096000], but what you now posted is:
You evidently had issues of some kind with datarescuedd.
You have a PARTIAL image.
We are doing a "Clone", so if the original is 976,768,065 sectors or 500,105,249,280 bytes, the copy, strangely enough, has to be the EXACT same size.
Go back to square #7:
and this time READ
the post and the given links.
In explorer the size of the image MUST be (Properties) EXACTLY 500,105,249,280 bytes.
Or if you need to do partial images, the re-assembled file MUST have the same exact size....
Still there is an inconsistency with the theoretical size as calculated from the MBR data, but that could be irrelevant or caused by some miscaòculation/corruption, all the other data seems like "consistent".
This post has been edited by jaclaz: 29 July 2012 - 07:06 AM