screwed up partition and data recovery

Here's my problem history:
-Installed a 250 GB Maxtor HD on a mobo via an on-board promise
controller: one big NTFS partition only. All worked.
-Users filled it up, they produce 4-10 Gb of data per day, making it
impossible to find a cost-effective backup strategy.
-The on-board promise controller stopped to work.
-I simply switched the disk to the ordinary ATA controller. The BIOS
was not reporting the disk size even with the last update (supposed to
support it).
-However windows2000 saw the disk & partition correctly.
-For other reasons I was asked to re-partition the disk, with
PartitionMagic. No matter how I tried but only the first partition was
visible to the OS. So I re built a huge partition, checked a few files
and returned the PC to its users (shame on me).
-Nothing wrong until windows does a chkdsk on an unattended boot-up.
-The event viewer reports a list of fixes on corrupted files so long
that is not complete.
-Apparently all the fixed files are now corrupted (still there,
reasonable size but unrecognizable format(s)).
-The size of the partition is reduced to some 194GB and so is the disk
(as reported in the mmc disk manager).
-I've installed it on a new PC, in order to have the disk recognized
perfectly from BIOS - worked. Still the OS (always win2000 SP4) sees
the disk as smaller.
-I've ran the maxtor disk checking utility and no error was detected
(for obvious reasons I've skipped the LowLevelFormat test).
-Testdisk form www.cgsecurity.org *does* recognize the error on the
MBR/partition table.
Now the question: is it possible to recover the damaged files?
Apparently, during or after the re-partitioning attempts, something
went wrong and all the files that were outside the "new" borders (of
what windows thinks is the disk size) have been broken down (thanks to
chkdsk). All the missing parts are probably still there at the end of
the disk, but is there a way to recover them at this point? Simply
correcting the MBR will not do the trick IMHO, I may be able to dig
out the lost raw data but not to fix the files killed by chkdsk.
Any idea?

Thanks very much and sorry for the long post,
Sergio Graziosi

-----------------------
Sergio Graziosi
Neurobiology Sector
SISSA/ISAS Trieste
www.sissa.it/~graziosi
-----------------------

confusing update:
Svend's Findpart output (using windows version)
*************
Disk: 3 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63404259597197392 0 1 1 25163 254 63 B OK?

No FATs found.

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK?
*************

If I got it right it is telling me that the partition is *larger* than
the disk itself. But in fact I know it's the opposite.
Strangely enough it is the same also with PartitionInfo from
PartitionMagic8:

****
Error #109: Partition ends after end of disk.
ucEndCylinder (25163) must be less than 16709.
****

In fact this may seem weird but I guess it can be explained: the
partition table is still right but windows thinks the disk to be
smaller.

Next step: I'm going tu run Findpart from dos and see if anything
changes. I'll post the results soon. I'm also checking again the bios
recognition FWIW.
Cheers,
Sergio

And here comes the dos findpart report:
********************
OS: DOS 6.22

Disk: 3 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63404259597197392 0 1 1 25163 254 63 B OK
0 - 0C406299915 83923560 40978 25291 0 1 30514 254 63 B OK
0 - 07 63469017612229012 0 1 1 29194 254 63 BU OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
25291 0 33 Second FAT not found.

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK
********************

If all this mess weren't my fault it would be worth a good laugh.
Would restoring the backup boot sector entry help fixing the messed up
files?
Why on earth am I getting different results if running findpart from
windows or dos? I'm trying to evoke the mighty Mikkelsen you see...
Take care,
Sergio

On 25 May 2004 07:07:38 -0700, (Sergio Graziosi)
wrote:

OS: DOS 6.22

Disk: 3 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63404259597197392 0 1 1 25163 254 63 B OK
0 - 0C406299915 83923560 40978 25291 0 1 30514 254 63 B OK
0 - 07 63469017612229012 0 1 1 29194 254 63 BU OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
25291 0 33 Second FAT not found.

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK

You should not cut the Findpart version number and Windows version
(other output). And when a 128 GB problem is present, you should not
cut output from other disks.

The disk is seen as full size in DOS, but not in Windows.

The partition table, and the boot sector of the 197392 MB NTFS
partition are OK. The internal condition of the partition is not
known.

A 40978 MB FAT32 partition, which may be internally OK, but which is
not in the partition tables is located at CHS 25291/0/1.

If we should do something about this case in the newsgroup, next step
would be that you do in Windows:

findpart tables fp-a.txt

and insert the output from fp-a.txt.

Then I will make a batch file to hide the partition on the disk in the
partition tables, and when done, the disk size problem should be
solved and further examination made.
--
Svend Olaf

(Svend Olaf Mikkelsen) wrote in message ...
You should not cut the Findpart version number and Windows version
(other output).

You are right: 4.43 for windows and 4.42 DOS.

And when a 128 GB problem is present, you should not
cut output from other disks.

I did ask findpart to look only at the troublesome HD. (the other HDs
I have are all smaller than 100 GB). But you are right again, I seem
to have underestimated the 128 GB limitation.

The disk is seen as full size in DOS, but not in Windows.

The partition table, and the boot sector of the 197392 MB NTFS
partition are OK. The internal condition of the partition is not
known.

Before we get to the details I'll post the tables output, but you'll
have to wait 24h since today I don't have physical access to the
affected system.

...snip...
Then I will make a batch file to hide the partition on the disk in the
partition tables, and when done, the disk size problem should be
solved and further examination made.

Hide what exactly?
Thanks very much anyway, your support is really appreciated,
Sergio

"Sergio Graziosi" wrote in message om...
(Svend Olaf Mikkelsen) wrote in message ...
You should not cut the Findpart version number and Windows version
(other output). And when a 128 GB problem is present, you should not
cut output from other disks.
snip
If we should do something about this case in the newsgroup, next step
would be that you do in Windows:

findpart tables fp-a.txt

and insert the output from fp-a.txt.

And here we go... I feel a just like an idiot. I didn't consider the
128 problem because I new I had the IAA installed. It was version 1.x.
(Ha Ha) And here is the tables output:

*****************
Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
[snip]

Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK?
****************

The disk n^2 is the troublesome one.
Now take a look at the disk after the installation of IAA 2.2:

****************
Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
[snip]

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63 404259597 197392 0 1 1 25163*254 63 OK OK
*****************

Looking at the positive side I may say that at least one problem has been
solved. Let me remind you that it is very likely that the last part of
the disk *does* contain valuable data from the original huge partition.

Then I will make a batch file to hide the partition on the disk in the
partition tables, and when done, the disk size problem should be solved
and further examination made.


I don't quite follow you here. If you are really so kind to send a batch
personalized for my means I suggest that you also help me understanding
what your strategy is, I know it would be the difficult part :-(.

One can always hope.

It sometimes helps to ask the question again.
And even then you may get a completely incomprehensible answer.


Thanks,
Sergio

"Sergio Graziosi" wrote in message om...
And here comes the dos findpart report:
********************
OS: DOS 6.22

Disk: 3 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63404259597197392 0 1 1 25163 254 63 B OK
0 - 0C406299915 83923560 40978 25291 0 1 30514 254 63 B OK
0 - 07 63469017612229012 0 1 1 29194 254 63 BU OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
25291 0 33 Second FAT not found.

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK
********************

If all this mess weren't my fault it would be worth a good laugh.
Would restoring the backup boot sector entry help fixing the messed up
files?
Why on earth am I getting different results if running findpart from
windows or dos?

I'm trying to evoke the mighty Mikkelsen you see...

What, he doesn't respond to email, does he?

Take care,
Sergio

"Svend Olaf Mikkelsen" wrote in message ...
On 27 May 2004 00:18:36 -0700, (Sergio Graziosi) wrote:

Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: Windows 5.0.2195 Service Pack 4 Partition tables:

Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63 40965687 20002 0 1 1 2549* 254 63 OK OK
0 2 0F 40965750 3100545 1513 2550* 0 1 2742* 254 63 OK
0 3 07 44066295 76019580 37118 2743* 0 1 7474* 254 63 OK OK

2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

-PCyl N ID -----Rel ------Num ----MB -Start CHS- ---End CHS-- BS CHS
0 1*07 63 404259597 197392 0 1 1 25163* 254 63 OK OK

From the original description it is not possible to predict what
happened, so there is nothing else to do than examine.

In my opinion it is necessary to hide the partition before examination,
since it is too confusing and dangerous if changes to the partition
happens during the examination, and eventually file copying.

If the partition is hidden you will not be able to access any files
using the operating system. It is done by editing the partition table,
so Windows will not see the partition, while the area containing the
partition is still reserved so new partitions cannot be made.

If you want to hide the partition, you can download sergio1.bat in

http://inet.uni2.dk/~svolaf/sergio1.zip

and run sergio1.bat, which contains:

set findpart=edit
findpart 2 0 1 - 27 0 0 2 30514 254 63 0 30515 255 63 26
set findpart=
findpart tables fp2-1.txt

The change will be effective after reboot.


You will depend on me to make another batch file to make the partition
visible to Windows 2000 again.

Not really.

--
Svend Olaf

"Sergio Graziosi" wrote in message om...
confusing update:
Svend's Findpart output (using windows version)
*************
Disk: 3 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63404259597197392 0 1 1 25163 254 63 B OK?

No FATs found.

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK?
*************

If I got it right it is telling me that the partition is *larger* than
the disk itself. But in fact I know it's the opposite.

Strangely enough it is the same also with PartitionInfo from PartitionMagic8:

So they are both flawed in the same department.
Which isn't really surprising when they look so very similar.


****
Error #109: Partition ends after end of disk.
ucEndCylinder (25163) must be less than 16709.
****

In fact this may seem weird but I guess it can be explained: the
partition table is still right but windows thinks the disk to be smaller.

The conclusion is still wrong.
Obviously the drive itself isn't checked and the info is gathered from
the OS or BIOS. Clearly the apps need to be updated to indicate whether
the partition table is in error or that the BIOS or OS is.


Next step: I'm going tu run Findpart from dos and see if anything changes.
I'll post the results soon. I'm also checking again the bios recognition FWIW.
Cheers,
Sergio

(Svend Olaf Mikkelsen) wrote in message ...
You should not cut the Findpart version number and Windows version
(other output). And when a 128 GB problem is present, you should not
cut output from other disks.
snip
If we should do something about this case in the newsgroup, next step
would be that you do in Windows:

findpart tables fp-a.txt

and insert the output from fp-a.txt.

And here we go... I feel a just like an idiot. I didn't consider the
128 problem because I new I had the IAA installed. It was version 1.x.
(Ha Ha) And here is the tables output:

*****************
Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: Windows 5.0.2195 Service Pack 4 Partition tables:

Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63 40965687 20002 0 1 1 2549*254 63 OK OK
0 2 0F 40965750 3100545 1513 2550* 0 1 2742*254 63 OK
0 3 07 44066295 76019580 37118 2743* 0 1 7474*254 63 OK OK

2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK

Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK?
****************

The disk n^2 is the troublesome one. Now take a look at the disk after
the installation of IAA 2.2:

****************
Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: Windows 5.0.2195 Service Pack 4 Partition tables:

Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63 40965687 20002 0 1 1 2549*254 63 OK OK
0 2 0F 40965750 3100545 1513 2550* 0 1 2742*254 63 OK
0 3 07 44066295 76019580 37118 2743* 0 1 7474*254 63 OK OK

2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK
*****************

Looking at the positive side I may say that at least one problem has
been solved. Let me remind you that it is very likely that the last
part of the disk *does* contain valuable data from the original huge
partition.

Then I will make a batch file to hide the partition on the disk in the
partition tables, and when done, the disk size problem should be
solved and further examination made.

I don't quite follow you here. If you are really so kind to send a
batch personalized for my means I suggest that you also help me
understanding what your strategy is, I know it would be the difficult
part :-(.

Thanks,
Sergio