Sender: Hechuan (hc), Board: DOS
【 Mentioned in Jungle's (Free Thorns~~Doing my own thing) post: 】
: 【 The following text is reposted from the Virus board 】
: 【 Originally posted by Jungle 】
: I'm trying to repair a hard disk damaged by CIH; both FATs on drive C are bad. 8-（
: When I copy it with ghost5.1c, it always says there is an illegal cluster (number: c000)
: Looks like I'll have to try repairing it by hand without copying.
: I've run into a problem now: I found the root directory (part of the files).
: The parameters of drive C are from (0,1,1) to (305,127,63) (cylinder, head, sector),
: 1204M, 512 bytes/sector, 63 sectors/head, 127 heads/cylinder,
: 64 sectors/cluster, that is 32k bytes/cluster
: Each FAT is 151 sectors (fat16)
: The root directory is at (1,6,26)
: At (31,72,20) I found a subdirectory whose starting sector is cluster 30757 (consistent with the entry in the root directory).
: How do you calculate the correspondence between physical sectors and clusters?
: (If I directly take cluster number x 64 and then add the end position of the second FAT, the result is wrong; but on other disks,
: including fat32 disks and 1G disks, this calculation is correct. I don't quite understand what's going on, hehe)
: How do I add the root directory information into the FAT?
: I'd appreciate it if all you experts could give me some advice, thanks!
FAT16 reserves the first two cluster numbers and doesn't use them, so it should be:
(cluster number - 2) * 64 + starting position of the data area, and that should be right.
Sender: Jungle (Free Thorns~~Doing my own thing), Board: DOS
In fact I've found that the calculation is much more complicated than that.
The main reason may be that the root directory is not immediately after the FAT table.
After summing it up 8-）：
Starting from a directory dir1 after the root directory, calculate the relative cluster number cl,
calculate sector count se = cl * 32 (it's actually not 64? Strange, the partition is over 1.1G)
then calculate relative cylinder count cy, revise se = se - cy * 63 (don't know why one head is missing from each cylinder)
Now se is the relative sector count between the cluster being calculated and the position of dir1.
(If I calculate from the root directory, there's still a discrepancy; I don't know why.)
Next, who can teach me how to fill in the FAT?
【 Mentioned in Hechuan's (hc) post: 】
: FAT16 reserves the first two cluster numbers and doesn't use them, so it should be：
: (cluster number - 2) * 64 + starting position of the data area, and that should be right.
Sender: Hechuan (hc), Board: DOS
【 Mentioned in Jungle's (Free Thorns~~Doing my own thing) post: 】
: In fact I've found that the calculation is much more complicated than that.
: The main reason may be that the root directory is not immediately after the FAT table.
: After summing it up 8-）：
: Starting from a directory dir1 after the root directory, calculate the relative cluster number cl,
: calculate sector count se = cl * 32 (it's actually not 64? Strange, the partition is over 1.1G)
: then calculate relative cylinder count cy, revise se = se - cy * 63 (don't know why one head is missing from each cylinder)
: Now se is the relative sector count between the cluster being calculated and the position of dir1.
: (If I calculate from the root directory, there's still a discrepancy; I don't know why.)
: Next, who can teach me how to fill in the FAT?
No way. Is your partition FAT16? Could it be that the conversion between relative sectors and physical sectors is wrong?
Sender: Jungle (Free Thorns), Board: DOS
I think it should be fat16; I asked the person who originally set up the disk.
And if it's fat32, then wouldn't this calculation method be even farther off? (4k, that is 8 sectors/cluster)
This 32 sectors/cluster is really too strange. A 1.2G disk should have 64 sectors/cluster.
But explaining it as fat32 doesn't seem quite right either.
Of course, the original system might have been win97. Would it do something bad?
Also: the root directory position in my original article was wrong. Later I calculated using a directory in another place;
this directory is correct, because I followed it and found several directories, including the document directory that most needs to be recovered.
Those are the directories from which I was able to summarize the pattern.
【 Mentioned in Hechuan's (hc) post: 】
: No way. Is your partition FAT16? Could it be that the conversion between relative sectors and physical sectors is wrong?
What's the difference between relative sectors and physical sectors? Surely the size can't be different too...
Sender: Hechuan (hc), Board: DOS
【 Mentioned in Jungle's (Free Thorns) post: 】
: I think it should be fat16; I asked the person who originally set up the disk.
: And if it's fat32, then wouldn't this calculation method be even farther off? (4k, that is 8 sectors/cluster)
: This 32 sectors/cluster is really too strange. A 1.2G disk should have 64 sectors/cluster.
: But explaining it as fat32 doesn't seem quite right either.
: Of course, the original system might have been win97. Would it do something bad?
: Also: the root directory position in my original article was wrong. Later I calculated using a directory in another place;
: this directory is correct, because I followed it and found several directories, including the document directory that most needs to be recovered.
: Those are the directories from which I was able to summarize the pattern.
: What's the difference between relative sectors and physical sectors? Surely the size can't be different too...
A 1.2G disk should have 32 sectors/cluster. Calculate it:
1.2*1024*1024*1024/65536 = 19660.8
By relative sectors I mean taking the first sector after the root directory as sector 0. Physical sectors are expressed by cylinder,
head, and sector.
I think manual recovery is too complicated. Better find some recovery tools (you may need to connect it to another hard disk),
such as RecoverNT, RecoverAll, Lost&Found. The Virus and pre-Win95 articles had very detailed introductions,
so you can write the recovered contents to another disk without changing the original disk.
Even if you modify it manually, it's best not to directly change the FAT. Just manually write the files you find to another disk (using
DiskEdit).
(This article was copied using the S-Term article copy script)
==================================================
【 Mentioned in Jungle's (Free Thorns~~Doing my own thing) post: 】
: 【 The following text is reposted from the Virus board 】
: 【 Originally posted by Jungle 】
: I'm trying to repair a hard disk damaged by CIH; both FATs on drive C are bad. 8-（
: When I copy it with ghost5.1c, it always says there is an illegal cluster (number: c000)
: Looks like I'll have to try repairing it by hand without copying.
: I've run into a problem now: I found the root directory (part of the files).
: The parameters of drive C are from (0,1,1) to (305,127,63) (cylinder, head, sector),
: 1204M, 512 bytes/sector, 63 sectors/head, 127 heads/cylinder,
: 64 sectors/cluster, that is 32k bytes/cluster
: Each FAT is 151 sectors (fat16)
: The root directory is at (1,6,26)
: At (31,72,20) I found a subdirectory whose starting sector is cluster 30757 (consistent with the entry in the root directory).
: How do you calculate the correspondence between physical sectors and clusters?
: (If I directly take cluster number x 64 and then add the end position of the second FAT, the result is wrong; but on other disks,
: including fat32 disks and 1G disks, this calculation is correct. I don't quite understand what's going on, hehe)
: How do I add the root directory information into the FAT?
: I'd appreciate it if all you experts could give me some advice, thanks!
FAT16 reserves the first two cluster numbers and doesn't use them, so it should be:
(cluster number - 2) * 64 + starting position of the data area, and that should be right.
Sender: Jungle (Free Thorns~~Doing my own thing), Board: DOS
In fact I've found that the calculation is much more complicated than that.
The main reason may be that the root directory is not immediately after the FAT table.
After summing it up 8-）：
Starting from a directory dir1 after the root directory, calculate the relative cluster number cl,
calculate sector count se = cl * 32 (it's actually not 64? Strange, the partition is over 1.1G)
then calculate relative cylinder count cy, revise se = se - cy * 63 (don't know why one head is missing from each cylinder)
Now se is the relative sector count between the cluster being calculated and the position of dir1.
(If I calculate from the root directory, there's still a discrepancy; I don't know why.)
Next, who can teach me how to fill in the FAT?
【 Mentioned in Hechuan's (hc) post: 】
: FAT16 reserves the first two cluster numbers and doesn't use them, so it should be：
: (cluster number - 2) * 64 + starting position of the data area, and that should be right.
Sender: Hechuan (hc), Board: DOS
【 Mentioned in Jungle's (Free Thorns~~Doing my own thing) post: 】
: In fact I've found that the calculation is much more complicated than that.
: The main reason may be that the root directory is not immediately after the FAT table.
: After summing it up 8-）：
: Starting from a directory dir1 after the root directory, calculate the relative cluster number cl,
: calculate sector count se = cl * 32 (it's actually not 64? Strange, the partition is over 1.1G)
: then calculate relative cylinder count cy, revise se = se - cy * 63 (don't know why one head is missing from each cylinder)
: Now se is the relative sector count between the cluster being calculated and the position of dir1.
: (If I calculate from the root directory, there's still a discrepancy; I don't know why.)
: Next, who can teach me how to fill in the FAT?
No way. Is your partition FAT16? Could it be that the conversion between relative sectors and physical sectors is wrong?
Sender: Jungle (Free Thorns), Board: DOS
I think it should be fat16; I asked the person who originally set up the disk.
And if it's fat32, then wouldn't this calculation method be even farther off? (4k, that is 8 sectors/cluster)
This 32 sectors/cluster is really too strange. A 1.2G disk should have 64 sectors/cluster.
But explaining it as fat32 doesn't seem quite right either.
Of course, the original system might have been win97. Would it do something bad?
Also: the root directory position in my original article was wrong. Later I calculated using a directory in another place;
this directory is correct, because I followed it and found several directories, including the document directory that most needs to be recovered.
Those are the directories from which I was able to summarize the pattern.
【 Mentioned in Hechuan's (hc) post: 】
: No way. Is your partition FAT16? Could it be that the conversion between relative sectors and physical sectors is wrong?
What's the difference between relative sectors and physical sectors? Surely the size can't be different too...
Sender: Hechuan (hc), Board: DOS
【 Mentioned in Jungle's (Free Thorns) post: 】
: I think it should be fat16; I asked the person who originally set up the disk.
: And if it's fat32, then wouldn't this calculation method be even farther off? (4k, that is 8 sectors/cluster)
: This 32 sectors/cluster is really too strange. A 1.2G disk should have 64 sectors/cluster.
: But explaining it as fat32 doesn't seem quite right either.
: Of course, the original system might have been win97. Would it do something bad?
: Also: the root directory position in my original article was wrong. Later I calculated using a directory in another place;
: this directory is correct, because I followed it and found several directories, including the document directory that most needs to be recovered.
: Those are the directories from which I was able to summarize the pattern.
: What's the difference between relative sectors and physical sectors? Surely the size can't be different too...
A 1.2G disk should have 32 sectors/cluster. Calculate it:
1.2*1024*1024*1024/65536 = 19660.8
By relative sectors I mean taking the first sector after the root directory as sector 0. Physical sectors are expressed by cylinder,
head, and sector.
I think manual recovery is too complicated. Better find some recovery tools (you may need to connect it to another hard disk),
such as RecoverNT, RecoverAll, Lost&Found. The Virus and pre-Win95 articles had very detailed introductions,
so you can write the recovered contents to another disk without changing the original disk.
Even if you modify it manually, it's best not to directly change the FAT. Just manually write the files you find to another disk (using
DiskEdit).
(This article was copied using the S-Term article copy script)
==================================================
ko20010214
=================================
大功告成，打个Kiss!
ko20010214@MSN.com
神州优雅Q300C
Intel CeleronM 370处理器 | 256MbDDR内存
40G硬盘 | USB2.0 | IEEE 1394
13.3 ' WXGA 宽屏(16:10) | COMBO光驱
10/100M网卡 | 四合一读卡器
=================================
大功告成，打个Kiss!
ko20010214@MSN.com
神州优雅Q300C
Intel CeleronM 370处理器 | 256MbDDR内存
40G硬盘 | USB2.0 | IEEE 1394
13.3 ' WXGA 宽屏(16:10) | COMBO光驱
10/100M网卡 | 四合一读卡器