What Files Did CHKDSK Truncate?

Topic

New Reply

I used CHKDSK /F from an external CD to “fix” an old 100 GB XP drive that was running slow.  It reported a single set of cross-linked files, and “repaired” them.  Thereafter, the drive would no longer boot.

No report of which files CHKDSK  “fixed.”  My understanding is that truncating the pairs of cross-linked files is the only “solution” available to CHKDSK.  To me, this is not a fix, it is a potential disaster.  While cross-linked, at least one of the two files reads correctly.  Afterwards, neither one does — and you don’t know which ones they were.

Surely they could have recognized  that blind truncation of files is not a solution — or is that only me, and I’m missing something?  (If so, please tell me.)  Now they also no longer even mentions fragment files in the root directory.

Surely they could have at least reported best information file names from the relevant directories, to give a clue that would permit real repair of the system (by copying in fresh files).

Is there any product out there that does all this better than CHKDSK?

— AwRon

Reply | Quote

Replies

Cross linked means two files share the same disk location according to the FAT.
There is no way to know which file is incorrect unless you know what is in the files or have a reference file. CHKDSK makes assumptions to fix the cross linking and sometimes (always) this results in broken files.
The only solution to broken files is restore from backup.

I suggest you backup the disk and then repair the boot files / re-install Windows.

cheers, Paul

Reply | Quote

AWRon wrote:

Surely they could have at least reported best information file names from the relevant directories, to give a clue that would permit real repair of the system (by copying in fresh files).

CHKDSK actions can be found in the event viewer : https://askleo.com/how_do_i_see_the_results_of_a_chkdsk_that_ran_on_boot/

Is there any product out there that does all this better than CHKDSK?

None.

1 user thanked author for this post.

AWRon

Reply | Quote

Thank you for this enormously helpful response — the Ask Leo link is an absolute gem!

I had forgotten all about the Event Viewer.

Now, how do I read the Event Viewer from the non-bootable, but still passively accessible, machine, on some other machine?

Where do I find it on the source, and where do I put a copy of it on the target, so the target reads the one of interest, instead of its own?

— AWRon

Reply | Quote

AWRon, Alex and PaulT are right. Sometimes when a file is cross linked the “wrong path” is used.

The Root Directory has the name, attributes and first pointer to the file’s location on the drive called clusters. The File Allocation Table (FAT) has the pointers to the rest of the file’s clusters (this is FAT 32 mentioned). If two files accidentally get the same clusters pointed to in the FAT it can get weird. If the path is still by chance going the right way, it still runs. If it follows the wrong direction things can crash. It sounds like CHKDSK accidentally used the wrong path. This is not what you were hoping for and I understand your anger.

Now to fix that. Do you by chance have a Diskette drive on that PC? If so, do you have a bootable diskette laying around? In the old days we would put in the diskette and in DOS type SYS C: and over the files went and you were up again.

If you do not have a diskette drive but CD-ROM, would you have the XP Setup CD or a bootable CD (with XP) available?

XP seems a bit different. See this site below:

How to Repair or Replace Boot.ini in Windows XP by Tim Fisher from lifewire
https://www.lifewire.com/how-to-repair-or-replace-boot-ini-in-windows-xp-2624512
“How to Repair or Replace Boot.ini in Windows XP”

I am hoping you will have the old diskette drive and a diskette around.

Please keep us posted.

1 user thanked author for this post.

AWRon

Reply | Quote