screwed up partition and data recovery

[Sergio Graziosi]

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
-----------------------

 

[Sergio 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

 

[Sergio Graziosi]

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

 

[Svend Olaf Mikkelsen]

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.

 

[Sergio Graziosi]

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.

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

 

[Folkert Rienstra]

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.

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.

 

[Folkert Rienstra]

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?

 

[Folkert Rienstra]

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.

 

[Folkert Rienstra]

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.

 

[Sergio Graziosi]

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.

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

 

[Svend Olaf Mikkelsen]

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

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.

 

[Svend Olaf Mikkelsen]

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

The user (including you?) decides what to put in the newsgroup. The
advantage of the newsgroup is that we learn something about the 128 GB
problem, and that it for anyone interested can be found by search
afterwards.

I wonder how large a percentage of the 2000/XP 128 GB problems we see
here. One of 1000? 10.000? 100.000? It may be a major problem.

 

[Sergio Graziosi]

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

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.

And the examination will be done by means of...?

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.

That is clear.

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

Ok, since the purpose of my posts here is also to let other people
learn from my mistakes I am not afraid to ask for clarifications:
Your documentation on www. partitionsupport.com is useful but way far
from complete. IOW it does not allow me to understand what all the
numbers mean. Please correct me as needed and possibly fill in the
blanks. Let's go in order:
-"findpart 2 0 1"= work on disk 2, from the MBR partition table, first
entry,

- "-" = dunno, "27" = set partition ID to 27 useful to hide the
partition,

-"two spaces" I wonder if that means something, "0 0 2" = set
partition start to CHS 0,0,2. It appears that we are having a double
protection: changing the ID (but you report that win2000 does not
respect it) so we also report a false partition start 0,0,2 instead of
0,1,1. I guess that this is enough to confuse the OS and actually
prevent it to mess with my disk.

-"two spaces","0","two spaces" = I have no idea.
-"30515 255 63" = this is the disk geometry setting specifying that
there are 30515 Cylinders, 255 Heads and 63 Sectors.
-"two spaces","26" = again, I'm clueless.

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

Unfortunately you are right: I do not have access to the information
necessary to do it myself.
In summary: I think the batch file will not exactly "hide the
partition", but it will replace the current mess with a brand new
hidden partition that spans all over the disk.
All in all you are suggesting me (again) to make a big jump "out of
the blue and into the black", I don't know what will be the detailed
effect of your batch (although I *think* I'm close to knowing) and I
don't know what is coming next in your plan.
You will forgive me if I decide to take my time and wait for
clarifications.
Obviously, for some reason of yours, you are providing un-rewarded
help and I do know I have no rights whatsoever. I do appreciate the
time you dedicate me and I'm just trying to get the most out of it.
Thanks again,
Sergio

 

[Sergio Graziosi]

The conclusion is still wrong.
Obviously the drive itself isn't checked and the info is gathered from
the OS or BIOS.

I did figure that out myself, but thanks anyway.

Clearly the apps need to be updated to indicate whether
the partition table is in error or that the BIOS or OS is.

This is a very good suggestion, let's hope that Svend will find the
will and time to implement it.

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

 

[Sergio Graziosi]

The user (including you?) decides what to put in the newsgroup.

In fact I did not mail Svend at all.

I wonder how large a percentage of the 2000/XP 128 GB problems we see
here. One of 1000? 10.000? 100.000? It may be a major problem.

What strikes me is how much the issue seems to be underestimated. I
have my faults for not addressing it from the beginning, but it is
strange to notice how little fuzz is heard around on this topic. I
wonder how Average Joe might hear or learn something about it.

Cheers,
Sergio

 

[Folkert Rienstra]

In fact I did not mail Svend at all.

Oh, why not?

What strikes me is how much the issue seems to be underestimated.

I have my faults for not addressing it from the beginning, but it is
strange to notice how little fuzz is heard around on this topic.

Actually, a similar case was brought here that stopped less than a week ago.
Over 50 messages in the thread.

I wonder how Average Joe might hear or learn something about it.

By just doing the minimum of research?

 

[Folkert Rienstra]

The user (including you?) decides what to put in the newsgroup. The advan
tage of the newsgroup is that we learn something about the 128 GB problem,

Do we?
You made a questionable comment the other day that I responded
to and what did you do? You disappeared again, as usual.
When something is about to be learned, you do the disappearing act again.

and that it for anyone interested can be found by search afterwards.

Right, and one would be enough for that.
Modifying FindPart in such a way that it is clear what the problem is
should rid us of those "1000? 10.000? 100.000?" of identical messages
that we don't need.

 

[Svend Olaf Mikkelsen]

Ok, since the purpose of my posts here is also to let other people
learn from my mistakes I am not afraid to ask for clarifications:
Your documentation on www. partitionsupport.com is useful but way far
from complete. IOW it does not allow me to understand what all the
numbers mean. Please correct me as needed and possibly fill in the
blanks. Let's go in order:
-"findpart 2 0 1"= work on disk 2, from the MBR partition table, first
entry,

- "-" = dunno, "27" = set partition ID to 27 useful to hide the
partition,

-"two spaces" I wonder if that means something, "0 0 2" = set
partition start to CHS 0,0,2. It appears that we are having a double
protection: changing the ID (but you report that win2000 does not
respect it) so we also report a false partition start 0,0,2 instead of
0,1,1. I guess that this is enough to confuse the OS and actually
prevent it to mess with my disk.

-"two spaces","0","two spaces" = I have no idea.
-"30515 255 63" = this is the disk geometry setting specifying that
there are 30515 Cylinders, 255 Heads and 63 Sectors.
-"two spaces","26" = again, I'm clueless.


Unfortunately you are right: I do not have access to the information
necessary to do it myself.
In summary: I think the batch file will not exactly "hide the
partition", but it will replace the current mess with a brand new
hidden partition that spans all over the disk.
All in all you are suggesting me (again) to make a big jump "out of
the blue and into the black", I don't know what will be the detailed
effect of your batch (although I *think* I'm close to knowing) and I
don't know what is coming next in your plan.
You will forgive me if I decide to take my time and wait for
clarifications.
Obviously, for some reason of yours, you are providing un-rewarded
help and I do know I have no rights whatsoever. I do appreciate the
time you dedicate me and I'm just trying to get the most out of it.
Thanks again,
Sergio

The ID for an NTFS partition is hexadecimal 07. Normally 17 is used
for a hidden NTFS partition, but since I also suggest that the
beginning location of the partition is changed, to avoid having an
NTFS boot sector in the beginning of the partition, I use 27 so other
partitioning tools will not assume that the partition is a normal
hidden NTFS partition.

The parameters are explained on the screen by typing:

set findpart=edit
findpart editpart /?
set findpart=

The "26" is a catch all version number. The correct version number can
be used. The number of spaces does not matter.

The batch file makes an ID 27 partition from the second sector of the
disk 2 to the end of the disk 2 (disks numbered from 1).

 

[Folkert Rienstra]

On 28 May 2004 01:49:58 -0700, (e-mail address removed) (Sergio Graziosi) wrote:
[snip]
The "26" is a catch all version number.
The correct version number can be used.

Makes one wonder what the point of it is for using it at all.

 

[Sergio Graziosi]

Oh, why not?

You know it: to have the opinion of more than one single person.

Actually, a similar case was brought here that stopped less than a week ago.
Over 50 messages in the thread.

Thanks for the hint. Honestly, I was scared out from that thread at
message 10 (google numbering) by lines such as:
/quote

Also as example (first) convince Phoenix/Award
not to report cylinders larger then 1023 (for another disk):

Oh? Why should I make an ass out of myself?
The info on how to use Int13-AH=48h is quite clear.
/unquote

Maybe you can figure out yourself why.
Anyway, the thread does get informative later on, thanks again.

By just doing the minimum of research?

That IS the point, by doing a "minimum research" you will learn that
you simply need XP or Win2000 with the latest SP, or an UATA 6
controller, or the IAA installed. In all its adventures my disk always
met at least two of these requirements, hence the 128/137 limit was
sorted out from the possible causes of trouble. Your help allowed me
to realize that the situation is way more complicated.