Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!mephisto!mcnc!rti!bcw
From: bcw@rti.UUCP (Bruce Wright)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Stumpers
Summary: How the "lost clusters" got that way
Message-ID: <3404@rti.UUCP>
Date: 11 Jan 90 07:22:41 GMT
References: <21990002@hpvcfs1.HP.COM> <25A51804.9795@maccs.dcss.mcmaster.ca> <355@marvin.moncam.co.uk>
Organization: Research Triangle Institute, RTP, NC
Lines: 32

In article <355@marvin.moncam.co.uk>, emmo@moncam.co.uk (Dave Emmerson) writes:
> > $2)  I have always wondered why CHKDSK, when used with the /F parameter,
> > $    creates FILE0000.CHK files in the root directory.  Can anyone give me
> > $    a good explanation of this?
> > 
> 
> Fine, I guess that anybody who hasn't grasped that those are the 'lost
> chains made accessible' by now is never going to. But nobody has explained
> how they could get 'lost' in the first place. 

The usual way is that the computer got rebooted while there were files open.
Could be caused by any number of things:  power failure, hardware problems,
program bugs, user error (rebooting at inopportune times in the program).

This sort of problem tends to affect programs that use the old FCB format
file I/O calls more than those that use the more modern "handle" file I/O
calls, though it's possible with either one under the right (wrong?)
circumstances.

More rarely, the chains get lost because something corrupted the disk
directory structure.  For example, a directory might be clobbered by a
bug in a utility program (like the Norton Utilities, not to say that they
have such a bug, but that they are an example of the type of program that
might cause this kind of problem if they had a bug in them).  Or the disk
might develop a bad spot which renders part of the directory structure
unreadable, and hence the clusters in the corresponding files unavailable
until chkdsk is run.

There are probably other ways this sort of corruption can occur but this
gives the general idea ...

						Bruce C. Wright