I can give you some PTEDIT32 examples from my computer. This is to help
familiarize you with what might be more normal. Note - Partition Magic
doesn't like what it sees here, so I'm making no claim these tables
are perfect. Just that the values in the table, are "mostly sane".
<-- Start ---> <--- End -----> Sectors Total
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
0C 80 637 1 1 1023 254 63 10233468 40965687
0C 00 1023 254 63 1023 254 63 51199155 40965750
83 00 1023 254 63 1023 254 63 92164968 37495647
07 00 1023 254 63 1023 254 63 129660615 182916090
My disk apparently has a space at the beginning. The first partition
starts
at 10233468. If you add 40965687 (size) to the start value, that gives
the next start at 51199155. If I haven't made any typos, I think you'll
see my four primary partitions are stacked end to end, but there is a
blank
space in front of the first partition.
My first two partitions are FAT32 (0C). The third one is for Linux. The
fourth one is an NTFS data partition. That is based on the values I see
in the Type field. The first partition is bootable (and happens to
contained Win2K).
*******
Here is my second disk. On this one, there is no blank space before the
first partition. (I don't think Disk Management will start a partition
at 0, since the MBR is there, and Disk Management is going to try to
start partitions on track boundaries. The geometry specification claims
tracks contain 63 sectors, which is physically unlikely. It is a
convention
of sorts. That could account for starting at 63.)
<-- Start ---> <--- End -----> Sectors Total
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
0B 00 0 1 1 636 254 63 63 10233342
0C 80 637 1 1 1023 254 63 10233468 152215812
0C 00 1023 0 1 1023 254 53 162449280 4080510
07 00 1023 0 1 1023 254 63 166529790 92164905
That is three FAT32 partitions and an NTFS partition. The second partition
contains an OS ("Boot") and that is my WinXP C: partition. The first
partition
starts at 63, leaving a track at the beginning of the disk. And sector 0
actually
contains the MBR and the above table. Between the first and second
partition,
is a blank track.
63+10233342 + 63 = 10233468
I don't know why Disk Management did that.
10233468 + 152215812 = 162449280 so there is no space between the second
and third partition. Similarly, the third and fourth partitions are
right next to one another as well, with no space.
*******
OK, my third disk is a temporary, where I'm experimenting with a Ubuntu
install.
<-- Start ---> <--- End -----> Sectors Total
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
83 80 0 1 1 1023 254 63 63 300527892
05 00 1023 254 63 1023 243 63 300527955 12048750
00 00 0 0 0 0 0 0 0 0
00 00 0 0 0 0 0 0 0 0
In that example, there are two entries. The second entry is special, and
is
type 05. That is an "extended partition". It is a "container". It holds
multiple "logical partitions". This is how you manage to get more than
four
partitions on a hard drive. Three of them could be primary, while the
fourth
"extended" one, could hold a dozen logical partitions if you wanted.
The extended partition doesn't have to have all the contained space
used, so you can do as follows. In this example, there is room to make
another logical partition, within the extended one. Doing so, would
not alter the contents of the MBR/primary entries, as shown in the
above table. I can't tell from the above table, how many logical
partitions are within the Extended (there happens to be only one, a
Linux swap partition). All I can say, is the example disk above, has
a relatively small extended section (6.17GB)
+---------------+--------------------------------------------------+
| Primary (83) | Extended (type 05) |
+---------------+------------+------------+------------------------+
| Logical #1 | Logical #2 | Empty space |
+------------+------------+------------------------+
Notice, that in the example, we can't tell what partition type is
in Logical #1, and you'd need something other than PTEDIT32 to get
that info. I expect TestDisk would know what was there.
*******
If we look at your partition table, the first two are NTFS. The second
two have the Type field set to 00, so I presume there is nothing in
those partition entries. (Some BIOS support dynamic updating of MBR, and
attempts to access a recovery partition, may cause one of the other
partition
entries to be updated when it is needed. I'm guessing that mechanism isn't
being used here.)
33555007 + 41094719 overlaps with 41094782, so your partition table says
the first partition is long enough, to overlap the second partition.
That is *not* good. If that were true, a write operation on the first
partition, would corrupt the second partition.
Now, if we take 33554944 + 63, that gets us to 33555007. And putting a
track of spacing between partitions, might be a thing to do. The 33554944
number does not "ring any bells", and I cannot tell you why some tool has
loaded values like that. But at least the distance between 33554944 and
33555007 makes some sense.
Now, imagine the following. I've edited your table, to what I think makes
sense.
This is your original.
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
07 80 2 3 1 1023 254 63 33555007
41094719
07 00 1023 2 1 1023 254 63 41094782
314130169
00 00 2 2 0 2 2 0 33554944
33564944
00 00 2 2 0 2 2 0 33554944
33564944
My guess would be, the first two entries would make more sense if they
were as follows. (Hmmm. the 2 3 1 should probably be changed to 0 1 1
as well, to be consistent with the 63 sector start. Not sure what to
do with the 1023 2 1 yet.)
07 80 0 1 1 1023 254 63 63
41094719
07 00 1023 2 1 1023 254 63 41094782
314130169
The question would then be, why didn't TestDisk detect something at
sector 63 ?
NOTE - TestDisk is a "repair in place" program. Before selecting an
option like "Write", you want a backup of the sick drive. By doing
so, you can undo whatever experiments you try.
You can use "dd" to make a backup. You need enough space to hold the
entire sick drive somewhere. This is a port of "dd" for Windows.
http://www.chrysocome.net/dd
Say I run "dd --list" in an MSDOS (command) window. And I see
entries like this.
\\?\Device\Harddisk0\Partition0
link to \\?\Device\Harddisk0\DR0
Fixed hard disk media. Block size = 512
\\?\Device\Harddisk0\Partition1
link to \\?\Device\HarddiskVolume1
In that example Harddisk0\Partition0, is the entire disk contents
including
MBR. The Harddisk1\Partition1, represents the first partition on the
drive,
so using that would not backup everything.
Now, I can do a backup. The simplest command would be:
dd if=\\?\Device\Harddisk0\Partition0 of=C:\mybackup.dd
Here, I'm copying all the sectors from the disk, and holding them
in the file "mybackup.dd". If the source disk is 80GB, the mybackup.dd
file will be 80GB as well. In my example, the C: drive would
have to be of type NTFS (as NTFS supports files larger than 4GB in size),
and the C: partition would need at least 80GB of spare room on it.
Later, say I discover I screwed up the repair, and the sick disk is
now trashed. I can put back the data, in original sick form, by doing
dd if=C:\mybackup.dd of=\\?\Device\Harddisk0\Partition0
and that puts back everything, including the original sick partition
table and all the (scrambled) data. The command works in its
simplified form, because "dd" can detect the "end" of the
disk, and knows when to stop. If you use this simple syntax with
a USB flash drive, there is a bug in "dd" and it won't stop at the
end properly. To prevent that, there are block size (bs) and count
parameters, to more precisely control the size of transfer. But
we don't need to worry about that now.
Before starting a "dd" transfer, you'd run HDTune first and do a
bad block scan. The purpose of checking for bad blocks, is to determine
whether the "dd" command is going to be able to capture all the data.
If HDTune shows all "green" squares, you're then ready to use the "dd"
command to make your backup.
*******
OK, we've made the backup, so we're protected against "repair-in-place"
accidents. We've done the extra work, to protect your daughter's data.
Now, if we were to edit the partition table, and change the start of
the first partition to 63, in principle, that makes the partition
table look a little more sane.
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
07 80 0 1 1 1023 254 63 63
41094719
07 00 1023 2 1 1023 254 63 41094782
314130169
The first partition is 21,040,496,128 bytes. The second
partition is 160,834,646,528. Hmmm. So the total disk must be
at least 181,875,142,656. I don't think I like this either.
Something still isn't right! You stated in a previous post,
that the disk is 160GB. It would then not be valid,
for the second partition to have a size of 160GB. It would
run "off the end". 314130169 * 512 = 160,834,646,528.
At this point, about all I can suggest, is to try to use TestDisk
to do a "deeper scan" or the like, to see if it can figure it out.
It seemed, from the messages you got, that it was looking at
the boot sectors at the beginning of the partition, and didn't
like what it found. The MBR itself, has a small piece of code that
starts the boot process. But there are also sectors within
the partition itself, which aid the boot process. And corrupting
those sectors will prevent booting. In Recovery Console, you
use "fixboot" to repair those sectors. (Note - don't do that
right now, because your partition table is a mess!)
+-----------------------------------------------------+-- - -
| MBR | Partition Boot Sectors , File system |
| | <------ entire partition ---------------->|
+---------+-------------------------------------------+-- - -
The problem I see right now, is there are at least two errors in
your MBR partition table entries. If there was only one significant
error, we could experiment with it and see what happens (by starting
the first partition at sector 63). But at least one partition has
a suspect partition size. And this is where, some knowledge about
what is "reasonable" for a value, helps.
If the partitions themselves are scrambled, now we have at least
three faults with the structure of the disk. Unless you've got
very good auxiliary information to work with, it is then getting
less and less likely, that you're going to find anything.
You can always try a scavenger, and see what it finds. I don't know
how much scrambling this tool can take. I don't really know what
it uses for a cue, for where the data is located. If it relied on
the partition table alone, it would be in deep trouble.
http://www.pricelesswarehome.org/WoundedMoon/win32/driverescue19d.html
Paul
