• Please review our updated Terms and Rules here

Chkdsk files generation

yorkie

Member
Joined
Sep 30, 2022
Messages
36
Location
The Workhouse, UK
Hi all,

When doing a chkdsk on a partition it created "found000" --> file000.chk files etc.

What did we use in 'days of yore' to view and save any segments?

A search on the web basically just throws up solutions for v7-->11 with the use of Event Viewer or Powershell. These will not be present on earlier versions of Windows or indeed have DOS equivalents.

Any utility app that one can recall for the earlier (simpler) days that will the .chk file. Not the log file as that is in clear.

Kev
 
We used "rename" or "move" and perhaps "copy" with concatenation. Much of the "found" clusters are orphan from files being written and not closed and have no meaning at all, their parent files having long vanished.
 
We used "rename" or "move" and perhaps "copy" with concatenation. Much of the "found" clusters are orphan from files being written and not closed and have no meaning at all, their parent files having long vanished.

Yes, I always used "del" or "erase" to deal with these files. :)
 
Thanks for the replies!

Only had a look via a text editor until some forum member could give a better way.

One file starts (relative) with PK and about 12 lines in gives a DLL file name from Windows\system. About another twelve lines into the chk file is another DLL file from Windows/System.
After looking at about 10% of a 6 MB with only those pointers, I believe the file(s) are linked to zipping a partition prior to backup. Just a guess though at this moment in time.

Kev
 
Now that you see the start of the file is PK, try changing the extension from .chk to .zip and then you can use any unzip program to look into it. (Of course, an unzipper of the same era as the file is best to insure feature match up with the supposed zip file.)
 
Good pointer. I'll give it a try but I'm going to guess that as the file(s) contained within the zip might not be complete and it probably will be missing the EOF marker then pkzip will give an error. Still........!

Kev
 
I've been using LIST for about the same, but I'm sure if it's the same version (registered user). Looks like the one that I linked to is probably his last incarnation, since it refers to Windows 95.
 
Yeah, non of us are immortal. Which brings it's own questions when one takes into account scientific progress on DNA type research. Cloning etc., etc. --> no end of life!

Anyways, just read a Microsoft comment within the post Win95 -> Win98 period that CHK files cannot be read by anything. Which is probably, technically, truthfully correct. I've not come across anything, including LIST, that will be the "Holy Grail". The problem is that the original use of clusters, which, at that time, were linked and thus readable to the OS or application. Then something happens and the cluster index is corrupted/destroyed. Then programs like Chkdsk/Scandsk etc find these "unallocated" clusters and stack them in the order that it found them. However, The original file(s) were probably using different clusters over a range of the disk. Thus a utility that "stacks" found unallocated clusters into a single file will be just random in nature.
I'm slightly surprised that no-one, in the early pc years of programming, was able to work out the original linking and produce more readable results. Perhaps there was some such successful efforts and the "Guardians" hoovered them up for their own purposes......????

The point is, if the file(s) is not saveable, then why produce a "dump" of unallocated clusters which will be of no use to man or beast. It would be much simpler to mark them once again as available for storage!

Kev
 
The point is, if the file(s) is not saveable, then why produce a "dump" of unallocated clusters which will be of no use to man or beast. It would be much simpler to mark them once again as available for storage!
Because sometimes it IS salvagable. And sometimes that data is important. If someone had a word processor open, and that word processor kept the file open for writing (how some word processors delt with very large files) and then it crashed... chkdsk might be able to recover it.

It was more effective on floppy disks where a crash or messed up FAT would not generate as many files and fewer fragments. On a hard disk, if one regularly keeps the drive defragmented then recovered files are much more likley to be useful.

As for viewing them, it is almost always a matter of using a hex editor like the Norton Utilities disk editor, manually identifying the format based on visible headers or content, and piecing fragments togeather by hand.

Generic file type viewers are not likley to be too helpful as they usually won't view incomplete file fragments, often won't recognize file formats if the file name extenstion is incorrect, and probably won't know what YOUR specific data is anyway.
 
Exactly. I have to go back to the source, but I was under the impression that Win and probably later MSDOS allocated new files on the basis of "next available cluster" rather than "first" which gives the user of, say, unerase, a fighting chance.
 
Someguay,

Yes, it is more than likely that ASCII files or part files can be re-constituted. That is why one will hear of some program or other being able to read a chk file. Even in a hex editor (and I've used them) still has the issue of determining (identifying) the next cluster. That next cluster might be 2MB into the file and the one need next might be 1MB previous.

Kev
 
Back
Top