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

[Folkert Rienstra]

[snip]

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.

You are welcome. Yet from the continuation of this thread, seems that you can
still make use of it for the corrupted FAT, provided you haven't already copied
FAT1 over FAT2, or vice versa (as with Scandisk, or DiskEdit).

Too late :-( And Svend's was the better option anyway, far less hassle.
But it is an interresting feature that may have its use for other purposes as
well. It would be even more useful if it wasn't limited to sector boundaries.

If you could define markers for areas to compare (e.g. CR or LF) it would
be a phenomenal tool to create a new file out of any 2 files, whether fixed
or free record.

 

[Joe Morris]

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

Yep. When the damnfool tech screwed up a user's system and there
was a deliverable due that morning, you use the tools at hand.

Thankfully the files that FDISK had scribbled on were either recoverable
from other sources or unwanted. It didn't hurt that the partition was
relatively small (FAT16 under NT) so I didn't have to search an
unmanageable number of sectors. DiskEdit to the rescue!

And not only the tech but the entire contractor for which he worked
are long gone. Good riddance...

Joe Morris

 

[Folkert Rienstra]

That was the first 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.

What about this line? It only shows up in Findpart. How do I get rid of it.

The line beginning with "376 1" is confusing,

But the endcylinder 1752* in the line before that, is not?

since it does not give the correct partition location.

Oh, what is wrong with it?
AFAICT, it's a partition boot record, not an EPBR pointer record.

The reason may be that the situation would not occur by natural causes,

and is not caught by Findpart.

Caught, meaning what, if it not the NB.

There however is an NB in the CHS field to indicate a problem.

So is there in the line above it.

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

Yes, although PartInfo suggests that both are large drive place holders.

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


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

Yes, but no indication that it is by F6 sectors. May I suggest an indicator:
How does F6 sound?

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

No problem.

Of course not, as I have no idea of what you are talking about :-(

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.

Water under the bridge.

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.

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

I changed the values less than 1024 back to 'actual'.

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 376 0 1 1105*254 63 133 OK
376 1 0B 63 11727387 5726 376 1 1 1105*254 63 OK OK
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 1758
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 133 0 1 1105*254 63 OK

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

376 1 0B 63 11727387 5726 376 1 1 1105*254 63 OK OK


Note that Findpart is not displaying the 1023 field value, but 1105 instead.


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


Partition Information Program
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 133 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 376 0 1 05 1023 254 63 6040440 11727450
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 376 1 1 0B 1023 254 63 6040503 11727387
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

Note that PartInfo is correctly displaying the 1023 field value, not 1105.

 

[Svend Olaf Mikkelsen]

What about this line? It only shows up in Findpart. How do I get rid of it.

By making the backup boot sector in the partition match the boot
sector.

But the endcylinder 1752* in the line before that, is not?


Oh, what is wrong with it?
AFAICT, it's a partition boot record, not an EPBR pointer record.

The only way to know the partition location from that line is the
Relative entry.

Caught, meaning what, if it not the NB.

The line should have listed the correct location.

So is there in the line above it.

Yes, but in the search part of the output entries for actual
partitions are more important than links to next extended partition
table.

Yes, although PartInfo suggests that both are large drive place holders.

They are. Although there is no standard, no tools however will use
1023 for cylinder numbers 1023 and lower.

Yes, but no indication that it is by F6 sectors. May I suggest an indicator:
How does F6 sound?

This is the first case ever with F6 on the same locations in both FAT
copies. Normally users will not edit the boot sector, and if editing
is to be done, the FAT should be edited first. In the first output
"Rep" was used.

Of course not, as I have no idea of what you are talking about :-(


Water under the bridge.



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

I changed the values less than 1024 back to 'actual'.

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 376 0 1 1105*254 63 133 OK
376 1 0B 63 11727387 5726 376 1 1 1105*254 63 OK OK
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 1758
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 133 0 1 1105*254 63 OK

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

376 1 0B 63 11727387 5726 376 1 1 1105*254 63 OK OK


Note that Findpart is not displaying the 1023 field value, but 1105 instead.

A star in the cylinder field indicates that the field value is 1023.
When evaluating the output, the field value is not important. Before
discussing, you must accept that the number of cylinders is the total
number of sectors divided with heads and sectors per track.

Partition Information Program
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 133 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 376 0 1 05 1023 254 63 6040440 11727450
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 376 1 1 0B 1023 254 63 6040503 11727387
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

Note that PartInfo is correctly displaying the 1023 field value, not 1105.

Did you search the Partinfo output for 1105? A few years ago I used to
look at Partinfo output, and the first thing I did was to copy the
output to Wordpad, select landscape format, and cut all lines not
containing useful information.

 

[Svend Olaf Mikkelsen]

Yes? What hard work is involved?
Its not that any other simple solution is a piece of cake. Recovering file content
to another place may be easy, restoring that to the correct name and place isn't.

I have one old version, you can try if you want:

chsdir1i 1 376 1 33 11415 4 2 createfatfile

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

It will create a file "fat", and current Chsdir can use the FAT file
for file listing. If the FAT file should be good, I have no tool to
put it in place in a safely manner. Well chsdir1i may be able to do
it, but I have to examine that.

This would just be an attempt. This version assumes that the files
without FAT are not fragmented.

 

[Folkert Rienstra]

I have one old version, you can try if you want:

chsdir1i 1 376 1 33 11415 4 2 createfatfile

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

It will create a file "fat",

and current Chsdir can use the FAT file for file listing.

Unfortunately that doesn't appear to work:

Here is a summary using on_disk fats

Chsdir, version 1.5.

Disk 1 CHS: 1106/255/63 FAT Location: 376/1/33

Total clusters: 1461118 Cluster KB: 4
Last used cluster: 1461058 Reserved: 32
FAT sectors: 11415 Root cluster: 2

FAT used clusters: 1332061 FAT entries: 63750
Used clusters: 1273924 Entries: 65439
Directories: 2186 Directories MB: 10
Files: 63253 Files MB: 4821
Partition MB: 5707 Free MB: 504

Used clusters do not match the FAT.
NB files: 2256


Here is the summary using the chsdir1i fatfile

Chsdir, version 1.5.

Disk 1 CHS: 1106/255/63 FAT Location: 376/1/33

Total clusters: 1461118 Cluster KB: 4
Last used cluster: 1461119 Reserved: 32
FAT sectors: 11415 Root cluster: 2

FAT used clusters: 1461118 FAT entries: 0
Used clusters: 25082 Entries: 25082
Directories: 1053 Directories MB: 4
Files: 24029 Files MB: 1
Partition MB: 5707 Free MB: 0

Used clusters do not match the FAT.
FAT file used.
NB files: 23139

However, the same result comes up with a saved single Fat
file placed in \fat. So the suspicion lies with 'chsdir fatfile'.

If the FAT file should be good,

Well, that is quite a bit of a gamble with 'chsdir fatfile' not working
correctly to check it out.

Any chance of adding that 'fatfile' option to cyldir so that files may
be copied using a revised FAT? That would enable one to examine
the results without any changes to the on_disk FATs.
Of course, the same results could be achieved when that repair were to be
done 'on the fly'. Currently, damaged (marked NB) files are not copied.

 

[Svend Olaf Mikkelsen]

Unfortunately that doesn't appear to work:

Here is the summary using the chsdir1i fatfile

Chsdir, version 1.5.

Disk 1 CHS: 1106/255/63 FAT Location: 376/1/33

Total clusters: 1461118 Cluster KB: 4
Last used cluster: 1461119 Reserved: 32
FAT sectors: 11415 Root cluster: 2

FAT used clusters: 1461118 FAT entries: 0
Used clusters: 25082 Entries: 25082
Directories: 1053 Directories MB: 4
Files: 24029 Files MB: 1
Partition MB: 5707 Free MB: 0

Used clusters do not match the FAT.
FAT file used.
NB files: 23139

However, the same result comes up with a saved single Fat
file placed in \fat. So the suspicion lies with 'chsdir fatfile'.

You are correct. Thank you. The error is corrected in Chsdir version
1.9, available at my page.

Any chance of adding that 'fatfile' option to cyldir so that files may
be copied using a revised FAT? That would enable one to examine
the results without any changes to the on_disk FATs.
Of course, the same results could be achieved when that repair were to be
done 'on the fly'. Currently, damaged (marked NB) files are not copied.

Could be done.

 

[Folkert Rienstra]

Dikke veer in je reet, Svend Olaf Mikkelsen!


No idea what you were talking about.
The endresult is almost spotless, afaict.
Only 4 files lost after minor damage repair with scandisk.
Haven't checked all previously affected files, there's a lot of them.
But the few ones I checked looked good.

I have one old version, you can try if you want:

chsdir1i 1 376 1 33 11415 4 2 createfatfile

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

It will create a file "fat", and current Chsdir can use the FAT file
for file listing.

If the FAT file should be good, I have no tool to put it in place in a
safely manner.

Well, finding that appeared to be the bigger problem.

Well chsdir1i may be able to do it, but I have to examine that.

That would be nice.
Meanwhile I used Hex Workshop v3.11 to do that and I think it isn't
working correctly on that R/W part. When checking your fat1 dump a-
gainst the same by Hex Workshop the latter appeared some 20kB bigger.
Well, I figured that if that would similarly happen to a writeback of that
revised FAT I would only run marginally into fat2 -which would be diffe
rent anyway- so what the heck.

Ran checkdsk, which -besides complaining about FATs being different-
kept quiet until very near to the end, complaining about only 4 files.

Here's a new feather in your cap.
I didn't find any of this capability in your competitors products.

Btw, it appears that if you don't let scandisk align the FATs it
still does that anyway when you let it repair a file or directory.

 

[Svend Olaf Mikkelsen]

Dikke veer in je reet, Svend Olaf Mikkelsen!
Sure.


No idea what you were talking about.
The endresult is almost spotless, afaict.
Only 4 files lost after minor damage repair with scandisk.
Haven't checked all previously affected files, there's a lot of them.
But the few ones I checked looked good.

Sounds good.

Well, finding that appeared to be the bigger problem.


That would be nice.
Meanwhile I used Hex Workshop v3.11 to do that and I think it isn't
working correctly on that R/W part. When checking your fat1 dump a-
gainst the same by Hex Workshop the latter appeared some 20kB bigger.
Well, I figured that if that would similarly happen to a writeback of that
revised FAT I would only run marginally into fat2 -which would be diffe
rent anyway- so what the heck.

Ran checkdsk, which -besides complaining about FATs being different-
kept quiet until very near to the end, complaining about only 4 files.

Here's a new feather in your cap.
I didn't find any of this capability in your competitors products.

Btw, it appears that if you don't let scandisk align the FATs it
still does that anyway when you let it repair a file or directory.

As I understand it, you checked using Chsdir version 1.9 that the FAT
created using Chsdir1i.exe was promising, and managed to copy the FAT
to the first FAT copy of the partition using Hex Workshop. And that
Scandisk after that copied FAT copy 1 to FAT copy 2.

The Chsdir1i commands to copy the FAT file back would be in this
example:

chsdir1i 1 376 1 33 11415 4 2 repairfat <used clusters>

where the <used clusters> value is for check. This command will make
backup copies of the current FAT copies, and copy the file \fat to the
two FAT copies.

Still, copying files to another disk or partition is the preferred
method in a case like this.

I assume your partition tables and partitions are now fine, but to
verify it, I would need to see some output.