Fdisk trashed both FATs, any way to recreate a single good? (Rich text)

[Folkert Rienstra]

How does one tell a long story short?

Oh well, Fdisk wrote a whole bunch of F6 sectors all over the 2 FATs of
my E: partition (every 6 and 57 sectors) after I found that Fdisk didn't
show E: (but windows and DOS do) and I thought: let's see if it thinks that
it's free space or else occupied, can't be that risky, right? How very wrong!

Of course that wasn't the only thing but I managed to recreate the MBR and
EPBRs and reconstruct the bootrecord with help of another partition bootre-
cord, Findfat for FAT- and partitionsize data and Partedit to edit them in.

133 2 05 4755240 11711385 5718 376 0 1 1104 254 63 NB
429 0 1 1157 254 63 Actual?
Fdisk F6 sector 376 1 1

No signature CHS: 429 0 1

The above 4 lines mostly defined the problem: false startsector for EPBR
and EPBR bootsector overwritten with F6. Unfortunately no sign of FATs
overwritten with F6 too. Can you do something about that, Svend?


So all I'm left with now is 2 equally damaged FATs. Neither one is good
(assuming there should be no F6 in FATs) so I can't let Scandisk correct
them, copying one over the other (reverse to scandisk's) won't help either.

Any one know of a software that is capable of recreating both FATs with
the parts that are good (not F6) in either one of them?
Basically a Fdisk disaster recovery tool?
After that I can use scandisk to resolve whatever problem that may be left.

Other questions:
RESQDISK added the bad extended partition as a primary 3rd partition
(which I believe is totally ignored). I removed it with partedit which now
doesn't show it anymore. However Findpart still finds it. How to remove?

(Btw, I found several problems in RESQDISK apart from how it handles
the MBR. You should really bugcheck that program, Zvi.)


Findpart, version 4.33 - for Windows 95/98/ME/NT/2000/XP.
OS: Windows 4.10

Disk: 1 Cylinders: 1106 Heads: 255 Sectors: 63 MB: 8676

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 2136582 1043 0 1 1 132 254 63 B OK
Fdisk F6 sector 3 1 1
133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11711385 5718 376 0 1 1104 254 63 133 OK
376 1 0B 63 11711322 5718 376 1 1 1104 254 63 OK OK

376 - 0B 63 3903732 1906 376 1 1 618 254 63 BU OK

Fdisk F6 sector 377 0 1
Fdisk F6 sector 377 1 1

Unfortunately a lot more than those 2

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2083 4 2? 2083 0 0 0 030215 618
133 1 33 3805 4 2 3805 0 0 0 030215 1659
376 1 33 11415 4 2 10868 547 0 0 030215 5092

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 2136582 1043 0 1 1 132 254 63 OK OK
0 2 0F 2136645 3903795 1906 133 0 1 375 254 63 OK

133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11711385 5718 376 0 1 1104 254 63 OK

376 1 0B 63 11711322 5718 376 1 1 1104 254 63 OK OK



Findfat, version FF 2.6.
Searches for sectors which may be first sector in a FAT.

OS: DOS 7.10 WINDOWS 4.10

Disk: 1 Cylinders: 1106 Heads: 255 Sectors: 63 MB: 8676

Start cylinder: 376 End cylinder: 377

----- FAT CHS ----- LBA FAT look Distance
376 1 33 6040535 32
376 182 45 6051950 32 11415

Method 2:

----- FAT CHS ----- LBA Confidence Distance Type Sig
376 1 33 6040535 9958 32 OK
376 182 45 6051950 10101 11415 32 OK

 

[Svend Olaf Mikkelsen]

Any one know of a software that is capable of recreating both FATs with
the parts that are good (not F6) in either one of them?
Basically a Fdisk disaster recovery tool?
After that I can use scandisk to resolve whatever problem that may be left.

Findpart, version 4.33 - for Windows 95/98/ME/NT/2000/XP.
OS: Windows 4.10

Disk: 1 Cylinders: 1106 Heads: 255 Sectors: 63 MB: 8676

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 2136582 1043 0 1 1 132 254 63 B OK
Fdisk F6 sector 3 1 1
133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11711385 5718 376 0 1 1104 254 63 133 OK
376 1 0B 63 11711322 5718 376 1 1 1104 254 63 OK OK

376 - 0B 63 3903732 1906 376 1 1 618 254 63 BU OK

Fdisk F6 sector 377 0 1
Fdisk F6 sector 377 1 1

Unfortunately a lot more than those 2

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2083 4 2? 2083 0 0 0 030215 618
133 1 33 3805 4 2 3805 0 0 0 030215 1659
376 1 33 11415 4 2 10868 547 0 0 030215 5092

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 2136582 1043 0 1 1 132 254 63 OK OK
0 2 0F 2136645 3903795 1906 133 0 1 375 254 63 OK

133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11711385 5718 376 0 1 1104 254 63 OK

376 1 0B 63 11711322 5718 376 1 1 1104 254 63 OK OK

Method 2:

----- FAT CHS ----- LBA Confidence Distance Type Sig
376 1 33 6040535 9958 32 OK
376 182 45 6051950 10101 11415 32 OK

Findpart or Findfat can repair the FAT of the cylinder 376 partition
using good sectors from each FAT copy. The problem is if directories
and/or files are damaged too. Since FAT copy 1 is better than FAT copy
2, it could be guessed that the damage is limited to the FAT area, but
since you say "a lot more than those 2" and "every 6 and 57" sectors,
the damage may be of some unusual type, and directories and/or files
may be damaged. The 6 and 57 indicates that Fdisk was in "large disk"
mode, and then the damage area usually would be some cylinders,
depending on the size of the free area.

The boot sector of the cylinder 376 partition seems to be OK, but I
cannot be certain. Depending on how you edited, two partitions may
have same serial number, which normally is not a problem. Note that
the partition currently ends 1 cylinder before the end of the disk. If
this is the result of your editing, used clusters theoretically could
be in the last cylinder.

The entry for the extended partition is wrong, since the end cylinder
is 375, while it should be 1105.

I assume that the C: and D: partitions are OK and that you do not
attempt to access the E: partition.


You could do this (batch file is available):

To save a backup of the FAT copies, for the case that Scandisk or
something else is accidently run:

findpart getsect 1 376 1 33 22830 fat.bin noheader

To examine the condition of the partition with the current boot sector
(Chsdir will adjust for the FAT damage without telling):

findpart chsdir 1 376 1 1 summary fp-a.txt
findpart chsdir 1 376 1 1 files files.txt

To examine the condition of the partition with adjusted FAT, in the
case that the directory structure is damaged:

findpart cyldir 1 376 1 33 11415 4 2 cdir.txt fp-b.txt

To examine the FAT using another approach:

findpart findfat 1 376 1 33 11415 fp-c.txt


I have made the above commands available in a batch file in

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


If you want to repair the FAT and edit the entry for the extended
partition, the commands are (the number of cylinders is for check)
(folkert2.zip is available):

set findpart=edit
findpart 1 0 2 - 0F 133 0 1 1105 254 63 0 1106 255 63 26
findpart findfat 1 376 1 33 11415 repair 1106
set findpart=
findpart tables fp1-2a.txt
findpart findfat 1 376 1 33 11415 fp1-2b.txt

If you run the repair, you should not attempt to access the partition
during the operating system until after reboot. Also you may want to
boot to a floppy first, and examine from there.


If this was a case I had in email, I guess I would initially hide the
problem partition, so it would be certain that the partition is not
accessed by the operating system during examination and repair.

Note that the backup boot sector in the cylinder 376 partition is not
correct, but this is not important.

If the partition is repaired, files which may be damaged by Fdisk can
afterwards be located by searching for files containing "÷÷÷÷÷÷"
(ascii 246 characters). Also, if the F6 area is known, Findpart Cyldir
has options to locate damaged files.

 

[Zvi Netiv]

How does one tell a long story short?

Oh well, Fdisk wrote a whole bunch of F6 sectors all over the 2 FATs of
my E: partition (every 6 and 57 sectors) after I found that Fdisk didn't
show E: (but windows and DOS do) and I thought: let's see if it thinks that
it's free space or else occupied, can't be that risky, right? How very wrong!

Just curious, how did FDISK do that? AFAIK, FDISK only fills the boot sector
with F6, when creating a new partition.

Of course that wasn't the only thing but I managed to recreate the MBR and
EPBRs and reconstruct the bootrecord with help of another partition bootre-
cord, Findfat for FAT- and partitionsize data and Partedit to edit them in.

133 2 05 4755240 11711385 5718 376 0 1 1104 254 63 NB
429 0 1 1157 254 63 Actual?
Fdisk F6 sector 376 1 1

No signature CHS: 429 0 1

The above 4 lines mostly defined the problem: false startsector for EPBR
and EPBR bootsector overwritten with F6. Unfortunately no sign of FATs
overwritten with F6 too. Can you do something about that, Svend?

So all I'm left with now is 2 equally damaged FATs. Neither one is good
(assuming there should be no F6 in FATs) so I can't let Scandisk correct
them, copying one over the other (reverse to scandisk's) won't help either.

Any one know of a software that is capable of recreating both FATs with
the parts that are good (not F6) in either one of them?
Basically a Fdisk disaster recovery tool?
After that I can use scandisk to resolve whatever problem that may be left.

Other questions:
RESQDISK added the bad extended partition as a primary 3rd partition
(which I believe is totally ignored). I removed it with partedit which now
doesn't show it anymore. However Findpart still finds it. How to remove?

RESQDISK doen't add extended partitions unless you approve them. It isn't an
automated recovery tool, but user guided.

(Btw, I found several problems in RESQDISK apart from how it handles
the MBR. You should really bugcheck that program, Zvi.)

If you could be specific, then I will, of course.

Regards, Zvi

 

[Zvi Netiv]

Any one know of a software that is capable of recreating both FATs with
the parts that are good (not F6) in either one of them?
Basically a Fdisk disaster recovery tool?

Follows the description of an in house tool that we use for re-synchronyzing
corrupted FAT, sometimes seen after virus damage.

You first need to save the two FAT copies to files (registered RESQDISK does
that). The tool compares the two files and writes a third one, in increments of
512 bytes. When a mismatch between the input files is encountered, then the
user selects which of the two inputs should be used for output (the two sectors
are displayed as in RESQDISK and a trained user can easily tell which one is
good). When done, then all that rests is to write back the output file (the
repaired FAT) back to disk (registered RESQDISK does it).

In your case you can automate the process rather than do it manually, since you
only expect F6 sectors, not garbage like in ours. Or maybe one of Svend's
utilities does it?

Regards, Zvi

 

[Zvi Netiv]

Follows the description of an in house tool that we use for re-synchronyzing
corrupted FAT, sometimes seen after virus damage.

You first need to save the two FAT copies to files (registered RESQDISK does
that). The tool compares the two files and writes a third one, in increments of
512 bytes. When a mismatch between the input files is encountered, then the
user selects which of the two inputs should be used for output (the two sectors
are displayed as in RESQDISK and a trained user can easily tell which one is
good). When done, then all that rests is to write back the output file (the
repaired FAT) back to disk (registered RESQDISK does it).

In your case you can automate the process rather than do it manually, since you
only expect F6 sectors, not garbage like in ours. Or maybe one of Svend's
utilities does it?

The SincFAT utility is now available from http://resq.co.il/download/syncfat.exe

To use, save the first copy of the FAT you need to edit as FAT1 (mandatory
filename) and the other copy as FAT2. Run SyncFAT with the two files in the
current directory.

Once started, the use of SyncFAT is intuitive and self explanatory. The output
file with the merged FAT is created in the current directory, with the default
name 'OUT'. Rests to paste it back to disk, in the correct place.

Regards, Zvi

 

[Folkert Rienstra]

The SincFAT utility is now available from http://resq.co.il/download/syncfat.exe

To use, save the first copy of the FAT you need to edit as FAT1 (mandatory
filename) and the other copy as FAT2. Run SyncFAT with the two files in the
current directory.

Once started, the use of SyncFAT is intuitive and self explanatory. The output
file with the merged FAT is created in the current directory, with the default
name 'OUT'. Rests to paste it back to disk, in the correct place.

Thanks for the suggestion. Maybe it will come in handy another time.

 

[Folkert Rienstra]

I would think that the above is not OK as they overlap.
Actually partinfo says something to that effect, I'm just not quite sure
that it says it because of that 376 - 0B copy above.

============================ Partition Information ===========================
Volume Partition Partition Start Total
Letter:Label Type Status Size MB Sector # Sector Sectors
------------- --------------- -------- ------- --------- - --------- ---------
COS98FE FAT32 Pri,Boot 1043.3 0 0 63 2136582

ExtendedX Pri 1906.1 0 1 2136645 3903795

EPBR Log 1906.1 None - 2136645 3903795

D:WIN98FE FAT32 Log 1906.1 2136645 0 2136708 3903732

EPBR Log 5718.4 2136645 1 6040440 11711385

Warning #113: EPBR partition starting at 6040440 overlaps extended partition.

Warning: EPBR partition starting at 6040440 is without logical partition.

Free Space Pri 5726.3 None - 6040440 11727450

EICTURES FAT32 Log 5718.4 6040440 0 6040503 11711322

Error #113: Logical starting at 6040503 overlaps extended partition.

Findpart or Findfat can repair the FAT of the cylinder 376 partition
using good sectors from each FAT copy.

Aah, how the absence of good documentation can make you think that that
capability is not available.

The problem is if directories
and/or files are damaged too. Since FAT copy 1 is better than FAT copy
2, it could be guessed that the damage is limited to the FAT area, but
since you say "a lot more than those 2" and "every 6 and 57" sectors,
the damage may be of some unusual type,

It's just every 6 and 57 sectors starting from the start of the partition so
FAT1 and 2 are infected differently because of their non-track alignment.
I stopped Fdisk a few seconds after I saw the verify routine and had a bad
feeling about that. Ofcourse that was way too late already.

and directories and/or files may be damaged.

It appears not, see below.

The 6 and 57 indicates that Fdisk was in "large disk" mode,

Meaning?
6+57 is 63 is a track. Bootsectors are at the first sector in a track and
the reserve is at an offset of 6. Coincidence huh?
Sounds like it deliberately overwrites any possible bootsectors and reserve
bootsectors plus FATs. What's the connection with "large disk" mode?

and then the damage area usually would be some cylinders,
depending on the size of the free area.

Actually, it is only in the FATs.
It ended less than 57 sectors before directories start, although I can't
be sure now if it originally was that way, see below (scandisk mishap).

The boot sector of the cylinder 376 partition seems to be OK, but I
cannot be certain.

I believe it's OK as the LBA pointer was off, leading to C=429 i.s.o. 376.
(Thanks to ptedit that kept stubbornly showing 429 as the address of the
partition bootrecord).

Depending on how you edited, two partitions may have same serial number,

Yeah, didn't change that.
(Btw, I used Ontracks Ptedit where I have said Partedit before).

which normally is not a problem. Note that the partition currently ends
1 cylinder before the end of the disk.

Hmm, I don't think I touched that. Anything I tried must have gone to 429 0 1.

If this is the result of your editing, used clusters theoretically could
be in the last cylinder.

I'll change it if problems still arise and see if it makes a difference.

The entry for the extended partition is wrong, since the end cylinder
is 375, while it should be 1105.

Ahh! You are correct. However, the CHS values are ignored.

I thought this was OK because 1105 is above 1023, the max cylinder.
But I see now that numbers over 1023 are used elsewhere. Strange though.
I think I saw declining numbers on the ending cylinders on each next partition
on my other (reserve, dead interface) drive that is 18GB and has 4 partitions.
Also, other programs do not show 1106 where Findpart does.
Are you sure Findpart does display correctly?

Maybe this was causing my initial Fdisk non-problem?
Actually, no, as Fdisk now shows the E: partition again, still with that
same number there. As I said before, the CHS values are ignored.

I assume that the C: and D: partitions are OK and that you do not
attempt to access the E: partition.

Well, inquisitive minds and all that .....
I thought I made sure that the FATs were not made identical (ignore)
by checkdisk, but I have found that both FATs are now suddenly identical.
If you want that to happen, I'm sure it just won't. When you don't, it will.

So now my next question is: can the FATs bad parts be reconstructed from
the directory info? Tell me you thought of that too.

You could do this (batch file is available):

To save a backup of the FAT copies, for the case that Scandisk or
something else is accidently run:

findpart getsect 1 376 1 33 22830 fat.bin noheader

I assume that is Fat1 + Fat2, given the size.

To examine the condition of the partition with the current boot sector
(Chsdir will adjust for the FAT damage

without telling):

Perhaps it should. It may paint a too rosy picture.
Or perhaps I interpreted 'adjust' the wrong way?

findpart chsdir 1 376 1 1 summary fp-a.txt
findpart chsdir 1 376 1 1 files files.txt

To examine the condition of the partition with adjusted FAT, in the
case that the directory structure is damaged:

findpart cyldir 1 376 1 33 11415 4 2 cdir.txt fp-b.txt

How are these two (chsdir, cyldir) different, given that 'adjust' by chsdir?

To examine the FAT using

another approach:

Yes, that kept me busy for a while, trying to remember which of your pro-
grams I used to get a certain result that I would use for documentation.

findpart findfat 1 376 1 33 11415 fp-c.txt


I have made the above commands available in a batch file in

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


If you want to repair the FAT and edit the entry for the extended
partition, the commands are (the number of cylinders is for check)
(folkert2.zip is available):

set findpart=edit

Is this only for editpart or also for all other sub-utility write options?

findpart 1 0 2 - 0F 133 0 1 1105 254 63 0 1106 255 63 26

Editpart syntax, apparently, without the editpart keyword.

findpart findfat 1 376 1 33 11415 repair 1106
set findpart=
findpart tables fp1-2a.txt
findpart findfat 1 376 1 33 11415 fp1-2b.txt

If you run the repair, you should not attempt to access the partition
during the operating system until after reboot. Also you may want to
boot to a floppy first, and examine from there.


If this was a case I had in email, I guess I would initially hide the
problem partition, so it would be certain that the partition is not
accessed by the operating system during examination and repair.

???. What's the email connection?

Note that the backup boot sector in the cylinder 376 partition is not correct,

What makes you think that? I put it there. But yes, you are correct, I pro-
bably only edited one of them through Ptedit afterwards. I have now checked
and they did indeed differ. Not anymore ;-)

but this is not important.

If the partition is repaired, files which may be damaged by Fdisk can
afterwards be located by searching for files containing "÷÷÷÷÷÷"
(ascii 246 characters).

Have you actually checked that?
If I fill a file with Alt246 and check it afterwards with hex workshop
it shows F7h, not F6h. DOS's edit shows 246 as ÷ but notepad does not.

Also, if the F6 area is known, Findpart Cyldir has options to locate damaged files.

Is there also a way to locate damaged files due to the FAT damage?
The ones that scandisk will complain about?

Oh, and thanks sofar.

 

[Svend Olaf Mikkelsen]

Aah, how the absence of good documentation can make you think that that
capability is not available.

The normal procedure will be to copy files to another disk. It is
documented how to do that. One explanation is that every precaution is
made to prevent the program from doing any damage if wrong parameters
are used, but it is a large responsibility to write to many sectors.
As in Scandisk.

It's just every 6 and 57 sectors starting from the start of the partition so
FAT1 and 2 are infected differently because of their non-track alignment.
I stopped Fdisk a few seconds after I saw the verify routine and had a bad
feeling about that. Ofcourse that was way too late already.

That explains the unusual findings. I was not certain if you had cut
some F6 lines from the Findpart output.

Meaning?
6+57 is 63 is a track. Bootsectors are at the first sector in a track and
the reserve is at an offset of 6. Coincidence huh?
Sounds like it deliberately overwrites any possible bootsectors and reserve
bootsectors plus FATs. What's the connection with "large disk" mode?

I large mode, Fdisk will write to sector 1 and 7 in each track, in
"normal" mode Fdisk will write each sector 1 only, and in a smaller
area. The explanation probably is the FAT32 backup boot sector in
sector 7.

Ahh! You are correct. However, the CHS values are ignored.

The number of sectors value is wrong too.

I thought this was OK because 1105 is above 1023, the max cylinder.
But I see now that numbers over 1023 are used elsewhere. Strange though.
I think I saw declining numbers on the ending cylinders on each next partition
on my other (reserve, dead interface) drive that is 18GB and has 4 partitions.
Also, other programs do not show 1106 where Findpart does.
Are you sure Findpart does display correctly?

Yes. Findpart displays the actual values, in stead of the cylinder
field value. (Let us not discuss that now).

Well, inquisitive minds and all that .....
I thought I made sure that the FATs were not made identical (ignore)
by checkdisk, but I have found that both FATs are now suddenly identical.
If you want that to happen, I'm sure it just won't. When you don't, it will.
Well.

So now my next question is: can the FATs bad parts be reconstructed from
the directory info? Tell me you thought of that too.

No. You should recover data by copying to another disk (or partition).
And hope that the second FAT copy was copied to the first, and not the
other way (can be examined).

I assume that is Fat1 + Fat2, given the size.
Yes.



Perhaps it should. It may paint a too rosy picture.
Or perhaps I interpreted 'adjust' the wrong way?

Correct. The closest I get on my pages is: "To verify if a FAT
partition is OK, the Chsdir program can be used with the FAT1 and FAT2
options."

How are these two (chsdir, cyldir) different, given that 'adjust' by chsdir?

Chsdir will just follow the directory structure, while Cyldir will
search for lost directories.

Is this only for editpart or also for all other sub-utility write options?

It is very difficult to make Findpart write without knowing, but by
principle I will not let the program write without the environment
variable set. I set it in autoexec.bat.

Editpart syntax, apparently, without the editpart keyword.
Yes.


???. What's the email connection?

In email it is more easy to solve a case in steps, and go to next step
when the result of one step is confirmed.

Have you actually checked that?
If I fill a file with Alt246 and check it afterwards with hex workshop
it shows F7h, not F6h. DOS's edit shows 246 as ÷ but notepad does not.

I have checked that.

Is there also a way to locate damaged files due to the FAT damage?
The ones that scandisk will complain about?

Oh, and thanks sofar.

The Chsdir program with the "files" option will mark files which do
not have FAT with "NB". Due to the unknown condition of FAT for the
directories, it may difficult to get an exact picture.


I suggest this (knowing that the operating system is Windows 98):

1. The partition tables are corrected, and the problem partition is
made a hidden partition. If this is done by hiding the last logical
partition, the DOS/Windows partition table issues must be remembered,
if more than one disk is in the system.

2. You look at the partition using my fp.sys read only device driver.

3. Files are copied to another partition, eventually on another disk.
For files with FAT you can use fp.sys. For files without FAT you will
need another recovery program.


Fell free to do "findpart all fp-a.txt" and mail me the file fp-a.txt.
In then will suggest batch files. But I of course understand if you
want to do this yourself.

 

[Svend Olaf Mikkelsen]

Disk: 1 Cylinders: 1106 Heads: 255 Sectors: 63 MB: 8676

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 2136582 1043 0 1 1 132 254 63 OK OK
0 2 0F 2136645 3903795 1906 133 0 1 375 254 63 OK

PS. If you use Powerquest ptedit for the above line, the number of
sectors value should be 15631245, and the begin cylinder and end
cylinder values should be 1023. The number of sectors value is
(1105 - 133 + 1) * 255 * 63.

133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11711385 5718 376 0 1 1104 254 63 OK

376 1 0B 63 11711322 5718 376 1 1 1104 254 63 OK OK

To hide the above partition, the ID (type) hex 0B can be changed to
1B. Assuming no disk contain more than one primary visible FAT
partition, and all extended partitions in the system are type 0F (The
DOS/Windows bugs when the last logical partition is not a FAT
partition).

 

[Joe Morris]

Just curious, how did FDISK do that? AFAIK, FDISK only fills the boot sector
with F6, when creating a new partition.

FDISK will scribble over not only the boot sector and various parts of the
FAT areas, but also on sectors throughout the newly-created
partition. I've not had to work with this problem for maybe a decade
or so, but my memory says that the other scribbled sectors are at
head=0 sector=1, but on cylinders in a pattern I never figured out.

I've recovered from this failure in some cases by using Norton DiskEdit
to manually rebuild the boot sector (grab a boot sector from some other
hard disk partition, copy it to the trashed partition, and *carefully*
update the boot data fields), then use it to locate the overwritten
sectors in each FAT. The times I've run into this FDISK didn't scribble
over the same data sector in both FAT copies, so you can copy the good
sector to the bad (FAT1 -> FAT2, or FAT2 -> FAT1) to recreate the
file system.

You'll still have some unknown number of files and/or directory chains
that are broken; it will take some time but you can just search for
the F6 scribbles and figure out from the (now repaired) FAT tables
whether the sector is in use, and if so by what.

Joe Morris

 

[Svend Olaf Mikkelsen]

No, I didn't. I would have said so.
It appears that Findpart is not checking the FATs for F6h and only checks
specific locations like x x 1 ?

In the partition search, yes. If Fdisk had not been interrupted, there
would have been more F6 lines. In the FAT search every sector of the
FAT is examined.

OK. More to do with FATxxx then.

I meant Fdisk in "large disk" mode (not BIOS).

But it too is ignored. Well, at least as it is. Perhaps this has other ad-
verse effects when you delete and add new partitons, I don't know.
I don't think that it caused what happened to me.
Fdisk now displays my E: drive even with the current socalled 'wrong' values.

The number of sectors value in the entry for the extended partition
must be correct. Well, since there is no reason not to make it
correct, and since it most certainly will confuse partitioning tools
and/or operating systems if it is not.

So it is the other programs that display wrong (or adjusted).


So Findpart does NOT display correctly. Presumably you meant
to say " in the lines that say 'Actual' " and are merely comments?

Actually, I find that 'Actual' misleading because it is a chs repre-
sentation (Not CHS) of what the decimal numbers are leading to.

What I also fail to understand is how a 3 byte (24-bit) field
can contain a CHS of over 1023 255 63 when there is only 10
bits for C, 8 bits for H and 6 bits for S. Am I missing something?

The number of cylinders on a disk is the total number of sectors
divided with the number of heads and number of sectors per track.

The value in the partition table cylinder field is wrong if the
cylinder number is larger than 1023, but since it is not used, it does
not matter. In the partition table output, Findpart will show both the
field value and the actual value if the field value is not standard.

Bummer. An idea for a next version of Findpart perhaps?

This is the classical problem of recovering files in an formatted FAT
partition (files without FAT). If files were fragmented, it is not so
simple. Actually, I can do it already, but it is not so funny.

I don't have the space. I think of having scandisk limit the damage, (hoping
it doesn't do further damage than without doing that) and then let Filesync
compare partial backups against what's left and refresh the damaged files.
Then I'll have to see what is still left damaged that wasn't backed up and
find copies of that individually.

It has a price not to have current backup. The price can be a new
disk. But of course it may work without.

It was the other way. Not that it matters much.

It was not examined directly, but I guess you had about 345 F6 sectors
in the first FAT copy, and 202 in the second FAT copy. It is
surprising if Scandisk chose the wrong FAT copy. (Norton Disk Doctor
on the other hand would have damaged as much as possible before it
would crash).

I was not aware of that. I see there is a newer version now.
What does the 'fatfile' option do?

It will use the file \fat which can be the size of one or two FAT
copies.

Why the deviation from your normal keyword practice?
It looked like one of those secret options of yours while it is not.

It has to fit a line.

What I'm saying is -I guess- is that my system may be configured differently
than yours. Unless Windows's Find treats input as 'DOS like', this could be a
problem.

In a test I made, both files containing ascii 246 (F6) and 247 (F7)
would be found when searching for the characters typed by alt-246.

Difficult huh? That produced a textfile of size 4MB :-(
Several hundred thousand entries with maybe a hundred or two
NB entries. A filter option is a necessity if this is to be useful.

Btw, what does NB stand for?

Missing FAT.

In my opinion the partition should still be made hidden, and the
partition tables corrected, to give some time to think with the system
in a stable condition.

One possibility is to list and copy the files without FAT, assuming
the files are not fragmented. Still, the normal procedure now would be
to attempt to copy all files using a standard recovery program, so do
not complain that it is not documented how to do it. That is something
I can do in mail only.

 

[Folkert Rienstra]

PS. If you use Powerquest ptedit for the above line, the number of
sectors value should be 15631245, and the begin cylinder and end
cylinder values should be 1023.

That will make Zvi happy ;-)

The number of sectors value is (1105 - 133 + 1) * 255 * 63.

Current situation:
(I'm now totally confused:
If you make Findpart happy, PartInfo sucks
If you make PartInfo happy, Findpart sucks
you can't win)

Findpart, version 4.33 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2003.

OS: Windows 4.10

Disk: 1 Cylinders: 1106 Heads: 255 Sectors: 63 MB: 8676

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 2136582 1043 0 1 1 132 254 63 B OK
Fdisk F6 sector 3 1 1
133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11727450 5726 1023 0 1 1752*254 63 133 NB
376 1 0B 63 11727387 5726 1023 1 1 1752*254 63 OK NB
376 - 0B 63 11711322 5718 376 1 1 1104 254 63 BU OK

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2083 4 2? 2083 0 0 0 030215 760
133 1 33 3805 4 2 3805 0 0 0 030215 1675
376 1 33 11415 4 2 11058 0 0 357 030215 5020

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 2136582 1043 0 1 1 132 254 63 OK OK
0 2 0F 2136645 15631245 7632 1023 0 1 1995*254 63 NB
133 0 1 1105 254 63 Actual

133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11727450 5726 1023 0 1 1752*254 63 NB
376 0 1 1105 254 63 Actual

376 1 0B 63 11727387 5726 1023 1 1 1752*254 63 OK NB
376 1 1 1105 254 63 Actual


Partition Information Program (PartInfo)
Oct 08 1999 - DOS32 Version

=====================================================================

Disk 0: 1106 Cylinders, 255 Heads, 63 Sectors/Track.

The BIOS supports INT 13h extensions for this drive.

========================== Partition Tables =========================

Partition -----Begin---- ------End----- Start Num

Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects

--------- - ---- ---- ---- ---- -- ---- ---- ---- --------- ---------

0 0 80 0 1 1 0B 132 254 63 63 2136582

0 1 00 1023 0 1 0F 1023 254 63 2136645 15631245
Info: Begin C,H,S values were large drive placeholders.
Info: End C,H,S values were large drive placeholders.
Actual values are:
0 1 00 133 0 1 0F 1105 254 63 2136645 15631245

2136645 0 00 133 1 1 0B 375 254 63 2136708 3903732

2136645 1 00 1023 0 1 05 1023 254 63 6040440 11727450
Info: Begin C,H,S values were large drive placeholders.
Info: End C,H,S values were large drive placeholders.
Actual values are:
2136645 1 00 376 0 1 05 1105 254 63 6040440 11727450

6040440 0 00 1023 1 1 0B 1023 254 63 6040503 11727387
Info: Begin C,H,S values were large drive placeholders.
Info: End C,H,S values were large drive placeholders.
Actual values are:

6040440 0 00 376 1 1 0B 1105 254 63 6040503 11727387


Resqdisk now thinks that the extended partition starts at 1023.
It obviously never heard of large drive place holders.

 

[Zvi Netiv]

The normal procedure will be to copy files to another disk. It is
documented how to do that. One explanation is that every precaution is
made to prevent the program from doing any damage if wrong parameters
are used, but it is a large responsibility to write to many sectors.
As in Scandisk.


That explains the unusual findings. I was not certain if you had cut
some F6 lines from the Findpart output.


I large mode, Fdisk will write to sector 1 and 7 in each track, in
"normal" mode Fdisk will write each sector 1 only, and in a smaller
area. The explanation probably is the FAT32 backup boot sector in
sector 7.

These are quite surprising findings. Do you know if FDISK does that for the
entire space of the partition newly created, or just for the projected FAT area?

This could have great significance in data recovery as current methods assume
that creating a partition with FDISK modifies just the MBR and/or an extended
partition sector, and prepares the projected boot sector by filling it/them
(sector 1, and 7 if it's FAT-32) with F6h.

Regards, Zvi

 

[Svend Olaf Mikkelsen]

That was one error. The begin cylinder field should be the same as the
actual value, since the begin cylinder is less than 1023. The begin
cylinder field for the extended partition should be 133.

Findpart, version 4.33 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2003.

OS: Windows 4.10

Disk: 1 Cylinders: 1106 Heads: 255 Sectors: 63 MB: 8676

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 - 0B 63 2136582 1043 0 1 1 132 254 63 B OK
Fdisk F6 sector 3 1 1
133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11727450 5726 1023 0 1 1752*254 63 133 NB
376 1 0B 63 11727387 5726 1023 1 1 1752*254 63 OK NB
376 - 0B 63 11711322 5718 376 1 1 1104 254 63 BU OK

The line beginning with "376 1" is confusing, since it does not give
the correct partition location. The reason may be that the situation
would not occur by natural causes, and is not caught by Findpart.
There however is an NB in the CHS field to indicate a problem.

The 1023 in the cylinder field should only be used if the actual
cylinder is 1023 or larger.

The boot sector number of sectors field was changed to include the
last cylinder, as you know, but not the backup boot sector.

-----FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YYMMDD DataMB
0 1 33 2083 4 2? 2083 0 0 0 030215 760
133 1 33 3805 4 2 3805 0 0 0 030215 1675
376 1 33 11415 4 2 11058 0 0 357 030215 5020

Findpart will consider a FAT sector with hex F6 in both FAT copies as
bad. 357 of 11415 FAT sectors are damaged.

The ? at the primary partition FAT indicates that the root cluster
number could not be confirmed by search for root cluster. No problem.

Partitions according to partition tables on first harddisk:

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*0B 63 2136582 1043 0 1 1 132 254 63 OK OK
0 2 0F 2136645 15631245 7632 1023 0 1 1995*254 63 NB
133 0 1 1105 254 63 Actual

133 1 0B 63 3903732 1906 133 1 1 375 254 63 OK OK
133 2 05 3903795 11727450 5726 1023 0 1 1752*254 63 NB
376 0 1 1105 254 63 Actual

376 1 0B 63 11727387 5726 1023 1 1 1752*254 63 OK NB
376 1 1 1105 254 63 Actual

Another error was when I in my first reply said that the first FAT
copy was best. It should have been the second FAT copy as implied when
saying that the damage area could be limited to the FAT.

For Windows 98 the above partition tables are OK, since for extended
partitions type 0F the LBA values will be used, and the CHS entries in
the extended partition tables will not be used.

 

[Zvi Netiv]

FDISK will scribble over not only the boot sector and various parts of the
FAT areas, but also on sectors throughout the newly-created
partition. I've not had to work with this problem for maybe a decade
or so, but my memory says that the other scribbled sectors are at
head=0 sector=1, but on cylinders in a pattern I never figured out.

Svend suggests the same in (e-mail address removed)

I've recovered from this failure in some cases by using Norton DiskEdit
to manually rebuild the boot sector (grab a boot sector from some other
hard disk partition, copy it to the trashed partition, and *carefully*
update the boot data fields), then use it to locate the overwritten
sectors in each FAT.

I use RESQDISK for that purpose, naturally.

The times I've run into this FDISK didn't scribble
over the same data sector in both FAT copies, so you can copy the good
sector to the bad (FAT1 -> FAT2, or FAT2 -> FAT1) to recreate the
file system.

Copying FAT1 over FAT2, or the other way round, is not the best approach. When
such trashing occurs, then a better way is to take advantage of the fact that
the trashed sectors aren't aligned in both FAT copies, and one could rebuild an
almost perfect FAT from the asynchronously corrupted FAT copies. I made
available such tool (one of our in house utilities) from
http://resq.co.il/download/syncfat.exe.

Regards, Zvi

 

[Svend Olaf Mikkelsen]

These are quite surprising findings. Do you know if FDISK does that for the
entire space of the partition newly created, or just for the projected FAT area?

This could have great significance in data recovery as current methods assume
that creating a partition with FDISK modifies just the MBR and/or an extended
partition sector, and prepares the projected boot sector by filling it/them
(sector 1, and 7 if it's FAT-32) with F6h.

Regards, Zvi

Not for the entire space. But for some percentage of the free space.
The area is larger if the Fdisk "large disk" option (FAT32 support) is
used. Typically some thousands sectors will be filled with ascii hex
F6. I have seen many cases, but not one single where the FAT size was
a multiply of the number of sectors per track. Meaning that it has
always been possible to use the FAT.

The worst thing is that the damage will happen as soon as the Fdisk
create partition screen is entered, you do not need to create a
partition.

Looking at Fdisk damage was pretty much how I began, so my 4 year old
Cyldir program will use the damaged FAT correctly when copying files.
I do not know if other recovery programs do it.

You really should set up a test system, and try it.

 

[Joe Morris]

Copying FAT1 over FAT2, or the other way round, is not the best approach. When
such trashing occurs, then a better way is to take advantage of the fact that
the trashed sectors aren't aligned in both FAT copies, and one could rebuild an
almost perfect FAT from the asynchronously corrupted FAT copies.

That's what I said. Copy the good *sector* (singular) to overwrite
the bad one, whether it's FAT1 -> FAT2 or FAT2 -> FAT1 wherever you
find one that's been vandalized by FDISK.

I made
available such tool (one of our in house utilities) from
http://resq.co.il/download/syncfat.exe.

Where were you ten years ago when I needed the utility ? <grin>

Joe Morris

 

[Zvi Netiv]

That's what I said. Copy the good *sector* (singular) to overwrite
the bad one, whether it's FAT1 -> FAT2 or FAT2 -> FAT1 wherever you
find one that's been vandalized by FDISK.

I see.

Where were you ten years ago when I needed the utility ? <grin>

You mean you did it sector after sector with a disk editor? ;-)

Cheers

 

[Folkert Rienstra]

In the partition search, yes. If Fdisk had not been interrupted, there
would have been more F6 lines. In the FAT search every sector of the
FAT is examined.

This doesn't follow. Why are there only 3 'F6' instances then?

I meant Fdisk in "large disk" mode (not BIOS).

Yes, and I meant "More to do with FATxxx differences then".
The F6 isnt just written with Large disk support, only differently.

The number of sectors value in the entry for the extended partition
must be correct. Well, since there is no reason not to make it
correct, and since it most certainly will confuse partitioning tools
and/or operating systems if it is not.

Well, sofar Win98 doesn't give a shit.
Whatever I do to it, it still sees the E: logical drive.
As long as I keep the LBA-starts correct I'm fine as it is.
However Findpart and Partinfo get thouroughly confused by some values
used in CHS start and/or end.

The number of cylinders on a disk is the total number of sectors
divided with the number of heads and number of sectors per track.

The value in the partition table cylinder field is wrong if the
cylinder number is larger than 1023,

It cant be, it's physically impossible. It must be a display error,

but since it is not used, it does not matter.

It's impossible, unless I'm missing something.

In the partition table output, Findpart will show both the
field value and the actual value if the field value is not standard.

Well, then Findpart has a bug as it is displaying non existable numbers
for the Cylinder field values.

This is the classical problem of recovering files in an formatted FAT
partition (files without FAT). If files were fragmented, it is not so simple.

Aah, but we are talking files with partial FAT here (I think).

Actually, I can do it already, but it is not so funny.

I'm not laughing. Please tell.

It has a price not to have current backup. The price can be a new disk.
But of course it may work without.

I have 2 choices now: run scandisk and potentially loose access to files I
can currently still see but don't run any risk if I then synchronize the re-
maining files. Or I can synchronize potentially more files without running
scandisk but then run the risk of files deleted/replaced releasing space
that is still cross-referenced and may subsequently be overwritten again.
I'm unable to tell which will be the bigger risk.

It was not examined directly, but I guess you had about 345 F6 sectors
in the first FAT copy, and 202 in the second FAT copy. It is
surprising if Scandisk chose the wrong FAT copy.

Well, the F6 in Fat1 were still in the same place and the F6 in Fat2
had suddenly moved place so I have no other conclusion to offer.

I wouldn't be surprised if it didn't choose at all unless there are
clear and simple signs to which one is broken and which one is not.

(Norton Disk Doctor on the other hand would have damaged as much as
possible before it would crash).


It will use the file \fat which can be the size of one or two FAT copies.

Define \fat please.

It has to fit a line.


In a test I made, both files containing ascii 246 (F6) and 247 (F7)
would be found when searching for the characters typed by alt-246.


Missing FAT.

Yes, but what does >NB< stand for?

In my opinion the partition should still be made hidden, and the
partition tables corrected, to give some time to think with the system
in a stable condition.

One possibility is to list and copy the files without FAT,

If that is to mean my filter option, then yes, that would be
useful if then copied to a shadow/mirror directory structure.

assuming the files are not fragmented.

Fragmented is not an issue. You cannot get around that, whatever you do.
An issue is how to restore as much as is possible the damage done to the
allocation chains so that you don't have to backup and later restore files to
several 1000 different places. That is a complete pain. I can see all my files.
The names are correct, they are in the correct directory etc.

The only problem is that some are broken or break the application
reading them because they chain to false or otherwise reserved clusters.
Most of them start off correctly so the starting cluster is known.
Repairing the allocation chains -presuming contiguous space- would be a
great help. Scandisk can deal with eventually crosslinked clusters just fine.
Pictures can be loaded and saved back if necessary, shedding any excess ba-
gage. What wasn't sequential is lost anyway, whatever method you choose.

Still, the normal procedure now would be
to attempt to copy all files using a standard recovery program,

Yeah, but that is a complete pain in the neck as I already mentioned
Why does everyone who makes a program that is only minutely smarter
than those utterly simple ones immediately want big money for it?

 

[Svend Olaf Mikkelsen]

This doesn't follow. Why are there only 3 'F6' instances then?

In the partition search each head 0, sector 1, and head 1, sector 1 is
examined for F6 sectors. This gives the picture.

Well, sofar Win98 doesn't give a shit.
Whatever I do to it, it still sees the E: logical drive.
As long as I keep the LBA-starts correct I'm fine as it is.
However Findpart and Partinfo get thouroughly confused by some values
used in CHS start and/or end.

You have to include Fdisk in Windows 98.

Aah, but we are talking files with partial FAT here (I think).

The principle is the same.

I'm not laughing. Please tell.

It is a Chsdir version, which will use available FAT, and try to
reconstruct the missing parts, but it will require hard work to make
it work in each case.

I have 2 choices now: run scandisk and potentially loose access to files I
can currently still see but don't run any risk if I then synchronize the re-
maining files. Or I can synchronize potentially more files without running
scandisk but then run the risk of files deleted/replaced releasing space
that is still cross-referenced and may subsequently be overwritten again.
I'm unable to tell which will be the bigger risk.

It could be considered what would happen if all F6 sectors were
replaced with End of File markers. Or with links to next cluster.

Define \fat please.

A file named "fat" in the root directory of current partition.

Yes, but what does >NB< stand for?

Nota Bene.