HD gone after Word wrote the first sectors

[antonio__regina]

I am asking expert advice.
FACTS:
I got a secondary HD for data that I carry with me home/work (IDE HD,
bipartitioned Fat32). While I was saving a Word file, I noticed that
the HD had the red light open for far too long. Result: the word file
was saved in the very first sectors of the HD.
I tried (I had a backup of that sector) to put back the first sector
(Head 0, Cil. 0 Sector 1). I guess is the MBR. After that I was able to
recover the 2nd partition with all files. But the first partition no:
now I have a row drive for that, only with the right partition size.
The 30 or so sectors following the first sector contain still the text
of the Word file, in fact.
AFTERMATH:
I tried filerecoveryPro (demo version/recovery disabled) and it is able
to find the first partition in the HD with all folders/files intact.
The drive listed is indicated as noboot Drive. So I guess that the file
structure should be somewhere in the first partition.
1st QUESTION:
Apart buying Filerecovery Pro, can I try to search the file structure
(or partion table not sure what it is called) of my first partition by
using an hex editor and put it back where it should be?
2nd QUESTION:
More in general on the causes of the disaster. Could be it due to heat
problems? Is there a way to slow the HD down when is not in full use?
Or could it depend to the use of high point controllers for an HD that
is swapped to different Pcs? (btw, no bad Read/write sectors in the
HD)?
TIA

 

[Folkert Rienstra]

Goto www.partitionsupport.com, run findpart and email the results to the author.

 

[Rod Speed]

I am asking expert advice.
FACTS:
I got a secondary HD for data that I carry with me home/work (IDE HD,
bipartitioned Fat32). While I was saving a Word file, I noticed that
the HD had the red light open for far too long. Result: the word file
was saved in the very first sectors of the HD.
I tried (I had a backup of that sector) to put back the first sector
(Head 0, Cil. 0 Sector 1). I guess is the MBR. After that I was able
to recover the 2nd partition with all files. But the first partition
no: now I have a row drive for that, only with the right partition
size. The 30 or so sectors following the first sector contain still
the text of the Word file, in fact.
AFTERMATH:
I tried filerecoveryPro (demo version/recovery disabled) and it is
able to find the first partition in the HD with all folders/files
intact. The drive listed is indicated as noboot Drive. So I guess
that the file structure should be somewhere in the first partition.
1st QUESTION:
Apart buying Filerecovery Pro, can I try to search the file structure
(or partion table not sure what it is called) of my first partition by
using an hex editor and put it back where it should be?

2nd QUESTION:
More in general on the causes of the disaster.
Could be it due to heat problems?

That is very unlikely. Heat problems usually produce different results.

Is there a way to slow the HD down when is not in full use?

Yes, but you are a bit vague about the specifics of how the hard
drive is connected to the system. Sounds like you may be using
a removeable drive bay to move the drive between systems.

Or could it depend to the use of high point controllers
for an HD that is swapped to different Pcs?

That's possible, but you dont see many reports of the effect you got.

 

[Svend Olaf Mikkelsen]

I am asking expert advice.
FACTS:
I got a secondary HD for data that I carry with me home/work (IDE HD,
bipartitioned Fat32). While I was saving a Word file, I noticed that
the HD had the red light open for far too long. Result: the word file
was saved in the very first sectors of the HD.
I tried (I had a backup of that sector) to put back the first sector
(Head 0, Cil. 0 Sector 1). I guess is the MBR. After that I was able to
recover the 2nd partition with all files. But the first partition no:
now I have a row drive for that, only with the right partition size.
The 30 or so sectors following the first sector contain still the text
of the Word file, in fact.
AFTERMATH:
I tried filerecoveryPro (demo version/recovery disabled) and it is able
to find the first partition in the HD with all folders/files intact.
The drive listed is indicated as noboot Drive. So I guess that the file
structure should be somewhere in the first partition.
1st QUESTION:
Apart buying Filerecovery Pro, can I try to search the file structure
(or partion table not sure what it is called) of my first partition by
using an hex editor and put it back where it should be?
2nd QUESTION:
More in general on the causes of the disaster. Could be it due to heat
problems? Is there a way to slow the HD down when is not in full use?
Or could it depend to the use of high point controllers for an HD that
is swapped to different Pcs? (btw, no bad Read/write sectors in the
HD)?
TIA

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

OS: Windows 5.1.2600 Service Pack 2 All



Disk: 3 Cylinders: 19929 Heads: 255 Sectors: 63 MB: 156327

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
2679 1 0B 63225391887110054 2679* 1 1 16708*254 63 R0 OK
0 - 0B 43038198225391887110054 2679 1 1 16708 254 63 B OK
Fdisk F6 sector 11827 0 1
Fdisk F6 sector 11827 1 1

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
2679 1 33 27508 32 2 27508 0 0 0 05-05-11 48172

------FAT CHS ------LBA Confidence Distance Type Sig
0 1 35 97 8933 32 OK
0 168 17 10600 8941 10503 32 OK

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1 0F 43038135225391950110054 2679* 0 1 16708*254 63 OK
0 2*0C 63 43038072 21014 0 1 1 2678*254 63 NB OK

2679 1 0B 63225391887110054 2679* 1 1 16708*254 63 R0 OK


The boot sector and the backup boot sector are damaged, seen by the
fact that they were not located by Findpart.

A few times lately I have seen that the FAT in the beginning of the
disk is printed using the alternative FAT finding format with Distance
ect., even if the signature of the first FAT copy is present. I do not
know why, but the first sector of the FAT may be non standard in some
way. It may also be possible that sector 35 only is searched if a boot
sector is present.

For this reason we do not have the cluster size (without calculating)
and we do not have the root cluster number, which most often is 2.

findpart findfat 3 0 1 35 10503

may give that information.

One real question that nobody ever asked, is what Confidence is. But
the fact that second FAT copy has larger confidence may indicate that
the second FAT copy is better than the first, and that the first FAT
copy is damaged.

Meaning that to repair the partition, we must find cluster size and
root cluster, examine that the partition is OK using the second FAT
copy, if yes copy the second FAT copy to the first and construct a
boot sector and copy it into place.

For a FAT32 partition each FAT sector defines 128 clusters. The
cluster size then is: 43038072/(128*10503) = 32.01322, and since it
must be a natural number, it is 32 sectors, or 16 KB.

The root cluster may be 2 as said.

Then the command to copy the files may be:

findpart chsdir 3 0 1 35 10503 16 2 copy fat2

Do not expect to find a free or reliable tool to repair the partition,
although they may exist.

 

[Folkert Rienstra]

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

OS: Windows 5.1.2600 Service Pack 2 All



Disk: 3 Cylinders: 19929 Heads: 255 Sectors: 63 MB: 156327

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
2679 1 0B 63225391887110054 2679* 1 1 16708*254 63 R0 OK
0 - 0B 43038198225391887110054 2679 1 1 16708 254 63 B OK
Fdisk F6 sector 11827 0 1
Fdisk F6 sector 11827 1 1

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
2679 1 33 27508 32 2 27508 0 0 0 05-05-11 48172

------FAT CHS ------LBA Confidence Distance Type Sig
0 1 35 97 8933 32 OK
0 168 17 10600 8941 10503 32 OK

Partitions according to partition tables on third harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1 0F 43038135225391950110054 2679* 0 1 16708*254 63 OK
0 2*0C 63 43038072 21014 0 1 1 2678*254 63 NB OK

2679 1 0B 63225391887110054 2679* 1 1 16708*254 63 R0 OK


The boot sector and the backup boot sector are damaged,
seen by the fact that they were not located by Findpart.

What is the point of publishing the results here when
your explanation isn't covered by the report itself.

Who is to know that NB (Nota Bene) is actually the equivalent to -B
(not based on bootsector) AND -BU (not based on backup bootsector).
If you want to explain something then please do (explain).
Nota Bene is not exactly the most telling.

Like it is, this is just for your own self-gratification and no help to anyone else.

There is nothing to learn except for some quite obvious flaws in it which
you have been pointed out to on earlier occasions but do nothing about.

A few times lately I have seen that the FAT in the beginning of the
disk is printed using the alternative FAT finding format with Distance
ect., even if the signature of the first FAT copy is present. I do not
know why, but the first sector of the FAT may be non standard in some
way. It may also be possible that sector 35 only is searched if a boot
sector is present.

You are the author but you sound like you were discussing someone else's
product that you know nothing about so are guessing to what it does exactly.

For this reason we do not have the cluster size (without calculating)
and we do not have the root cluster number, which most often is 2.

findpart findfat 3 0 1 35 10503

may give that information.

One real question that nobody ever asked,

And a few dozen other questions no one ever asks too, so what.

is what Confidence is.

Like as if you will answer that question.

But the fact that second FAT copy has larger confidence may indicate that
the second FAT copy is better than the first, and that the first FAT
copy is damaged.

Meaning that to repair the partition, we must find cluster size and
root cluster, examine that the partition is OK using the second FAT
copy, if yes copy the second FAT copy to the first and construct a
boot sector and copy it into place.

For a FAT32 partition each FAT sector defines 128 clusters.
The cluster size then is: 43038072/(128*10503) = 32.01322,
and since it must be a natural number, it is 32 sectors, or 16 KB.

The root cluster may be 2 as said.

Then the command to copy the files may be:

findpart chsdir 3 0 1 35 10503 16 2 copy fat2

Do not expect to find a free or reliable tool to repair the partition,
although they may exist.

This is easily your weirdest post that I have seen to date.

 

[Rod Speed]

What is the point of publishing the results here

It allows us to see the washup, and pissed you off too. Wota bonus.



<reams of your puerile shit flushed where it belongs>

 

[Svend Olaf Mikkelsen]

Like as if you will answer that question.

The confidence is the number of FAT sectors which point to the FAT
location. Based on the fact that many files have some contiguous
clusters. Using this method, a FAT copy can be located, even if the
beginning of the FAT copy is lost.

 

[Odie Ferrous]

Like it is, this is just for your own self-gratification and no help to anyone else.

Pot. Kettle. Black.

Hi, Folkert.


Odie

 

[Arno Wagner]

I am asking expert advice.
FACTS:
I got a secondary HD for data that I carry with me home/work (IDE HD,
bipartitioned Fat32). While I was saving a Word file, I noticed that
the HD had the red light open for far too long. Result: the word file
was saved in the very first sectors of the HD.
I tried (I had a backup of that sector) to put back the first sector
(Head 0, Cil. 0 Sector 1). I guess is the MBR. After that I was able to
recover the 2nd partition with all files. But the first partition no:
now I have a row drive for that, only with the right partition size.
The 30 or so sectors following the first sector contain still the text
of the Word file, in fact.

Urgh. Pretty destructive on FAT.

AFTERMATH:
I tried filerecoveryPro (demo version/recovery disabled) and it is able
to find the first partition in the HD with all folders/files intact.
The drive listed is indicated as noboot Drive. So I guess that the file
structure should be somewhere in the first partition.

Actually you seem to find the directory structure. That is not at
the beginning of the partition. In order to get the files you need
the FAT (which is at the beginning of the partition) unless you
want to sole a gigantic puzzle.

1st QUESTION:
Apart buying Filerecovery Pro, can I try to search the file structure
(or partion table not sure what it is called) of my first partition by
using an hex editor and put it back where it should be?

If there was an intac FAT, e.g. the second copy, then yes. But
there likely is not.

2nd QUESTION:
More in general on the causes of the disaster. Could be it due to heat
problems?

No. Heat problems will kill a drive but will not cause it
to write (which is a comples operation) to the wrong space.
Sounds more like a defect driver to me.

Is there a way to slow the HD down when is not in full use?

Depends. You can set it to spin-down after a short time but that
is risky with non-notebook HDDs. Better improve cooling.

Or could it depend to the use of high point controllers for an HD that
is swapped to different Pcs? (btw, no bad Read/write sectors in the
HD)?

Could be. I don't think the HDD itself is to blame at all for
this problem.

Arno

 

[antonio__regina]

Thank you to all who contributed to help.
As regards findpart I can certainly run

findpart findfat 3 0 1 35 10503

What I will be absolutely sure is that nothing is written on the HD. I
think (looking to the first sectors) that boot sector and backup boot
sector is gone. But the structure files/folders of the HD-first partion
is hidden somewhere (see point below). Is there a way to locate it? Can
a program show the exact structure/files without a correct FAT (either
origianal or copy)?

Actually you seem to find the directory structure.

As regards with what I found with filerecovery I am not sure what it
is, but I am sure that the folder/files are where they should be; they
seem intact for size/date/etc. and (the program claims) they are
recovable.

No. Heat problems will kill a drive but will not cause it
to write (which is a comples operation) to the wrong space.

That it seems what is occured. Can one use normal controllers in a raid
motherboard, if the raid is not used, but it is used both the two IDE
connections for HDs?

Sounds more like a defect driver to me.

.....> I don't think the HDD itself is to blame at all for
this problem.
The HD is by now ok in its second partition. And it is pretty new.