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

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

On Wed, 25 Jun 2003 00:33:01 +0200, "Folkert Rienstra"
wrote:

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.
--
Svend Olaf
http://inet.uni2.dk/~svolaf/utilities.htm

"Folkert Rienstra" wrote:

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
--
NetZ Computing Ltd. ISRAEL http://invircible.com
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
E-mail sent in reply to this post will not be considered private and
will be answered in the newsgroup. Top posting is not appreciated!

"Folkert Rienstra" wrote:

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
--
NetZ Computing Ltd. ISRAEL http://invircible.com
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
E-mail sent in reply to this post will not be considered private and
will be answered in the newsgroup. Top posting is not appreciated!

Zvi Netiv wrote:

"Folkert Rienstra" wrote:

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?

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
--
NetZ Computing Ltd. ISRAEL http://invircible.com
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
E-mail sent in reply to this post will not be considered private and
will be answered in the newsgroup. Top posting is not appreciated!

"Zvi Netiv" wrote in message ...
Zvi Netiv wrote:

"Folkert Rienstra" wrote:

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?

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.


Regards, Zvi
--
NetZ Computing Ltd. ISRAEL http://invircible.com
InVircible Virus Defense Solutions, ResQ and Data Recovery Utilities
E-mail sent in reply to this post will not be considered private and
will be answered in the newsgroup. Top posting is not appreciated!

On Thu, 26 Jun 2003 00:31:12 +0200, "Folkert Rienstra"
wrote:

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

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?

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.

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.

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

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.

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

findpart getsect 1 376 1 33 22830 fat.bin noheader

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

Yes.

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?

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

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?

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

set findpart=edit

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.

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

Editpart syntax, apparently, without the editpart keyword.

Yes.

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?

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.

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.

I have checked that.

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.

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
http://inet.uni2.dk/~svolaf/utilities.htm

On Wed, 25 Jun 2003 00:33:01 +0200, "Folkert Rienstra"
wrote:

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).
--
Svend Olaf

Zvi Netiv writes:

"Folkert Rienstra" wrote:

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.

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

On Thu, 26 Jun 2003 21:38:08 +0200, "Folkert Rienstra"
wrote:

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

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.

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.

OK. More to do with FATxxx then.

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

The number of sectors value is wrong too.

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.

Are you sure Findpart does display correctly?

Yes.

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

Findpart displays the actual values, in stead of the cylinder field value.

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.

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.

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.

You should recover data by copying to another disk (or partition).

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.

And hope that the second FAT copy was copied to the first, and not the
other way (can be examined).

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

"To verify if a FAT partition is OK, the Chsdir program can be used
with the FAT1 and FAT2 options."

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.

Yes.

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.

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.

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.

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 be difficult to get an exact picture.

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.
--
Svend Olaf