John said:
I was trying to get rid of things identified as root kits on my
secondary hard drive. They may or may not be root kits, but I know
they aren't necessary. First, the drive's folders were copied to the
primary drive (the drive is also backed up on removable media). Using
a Western Digital utility (WinDlg.exe) zeros were written to the
first and last parts of the drive. I think that produced an error,
and maybe that's when the problem occurred. Windows no longer
identifies the drive as something it can mount or format or whatever.
It shows the drive, but (as I recall) a bar on the left-hand side
signifies that signifies there is no partition table. The drive shows
up okay in the BIOS.
So I'm trying this TestDisk utility.
After maybe 12 hours...
TestDisk 6.14-WIP, Data Recovery Utility, May 2012
Christophe GRENIER <
[email protected]>
http://www.cgsecurity.org
Disk /dev/sdb - 750 GB / 698 GiB - CHS 91201 255 63
Analyse cylinder 42455/91200: 46%
Thanks, for suggestions.
If you like the determination that TestDisk has made, you
ask TestDisk to "write out" the resulting MBR. If you just
quit after the scan, then nothing gets fixed.
To use TestDisk, you the operator, have to recognize whether
the determination is correct or not. If it finds one or more
partitions, you have to look at the size information, and decide
whether it's correct.
When the scan is done, it's done on some CHS boundary. A lot
of reads still result, but the entire disk doesn't have to be
read. (It looks for something "interesting", every 7.8MB or so.)
TestDisk should finish faster, than an attempt to read every
sector on the disk.
To give an example, I had a drive with four partitions,
I deleted a partition, and resized something else. Later,
I needed to run TestDisk, and it said I had four partitions
and would I like to write that back ? Of course, I could
not accept the suggestion, because the fourth partition
is a "ghost" sitting in the middle of the third partition,
and the sectors it occupies haven't been written yet. If
I said "yes" to the MBR write operation, eventually that fourth
partition is going to get mounted by Windows, and very quickly,
an operation done on it, will ruin the third partition.
So any time you use TestDisk, you can only "accept" the
computed partition table, if it makes sense. I knew the
history of my disk, and what that fourth partition in the
middle of nowhere, really meant.
Don't accept a partition table computation, on the gamble its
correct. If you're working on someone else's computer, trying
to repair it, you could easily ruin everything by accepting
a bad TestDisk output. TestDisk looks for info it suspects
is a partition, but TestDisk may not have sufficient logic
to see that "Partition four is right in the middle of
Partition three". Most of the "logic", comes from the
user's head, not from the tool itself.
If you have any question about the output, you can
1) Back up the disk, sector by sector, then let TestDisk mess around.
Restore, if things get ruined.
2) Alternately, use a "file scavenger" from Windows, to scrape any
recoverable files off the disk. Then, if you want to hammer it
with TestDisk, go right ahead. That way, you might get most of
the files off, before gambling on whether the TestDisk settings
are reasonable.
To check for a partition table, I recommend PTEDIT32.exe, available
as a free download. Runs in Windows. At least your Windows C: and
the disk it is on, should show up properly in there. This tool is
ancient, but for my workflow, is good enough. (Mostly MSDOS, CHS
type disks.)
ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip
If you run that in Windows 7, you have to "Run as Administrator" or
it gets an "Error 5".
In any case, when it runs, you see a dialog like this.
http://www.goodells.net/dellrestore/files/dell-tbl.gif
You can even "overtype" the numbers in there, and change stuff.
For example, I've manually swapped row 3 and row 4 in the table,
for two data partitions, to put them in spatial order. Normally,
the partition entries correspond to the physical layout, but
the partition table is not guaranteed to be in that order, and
a partition manager can do whatever it feels like. Before moving
a partition table entry like that, you have to be absolute sure
there are no side effects. If you move a bootable WinXP partition,
you have to edit boot.ini and change the ARC path, before WinXP
will boot again. If I had a Windows 7 partition, and I moved
it, I haven't a clue how you'd fix it. Maybe the automatic
recovery would get it, or maybe not.
Paul
