Path: utzoo!attcan!uunet!aplcen!samsung!usc!apple!motcsd!hpda!hpcuhb!hpcilzb!hpcea!hpdtl!conway
From: conway@hpdtl.HP.COM (Daniel F. Conway)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Stumpers
Message-ID: <13500004@hpdtl.HP.COM>
Date: 9 Jan 90 19:02:59 GMT
References: <21990002@hpvcfs1.HP.COM>
Organization: HP Design Tech. Lab., Palo Alto, CA
Lines: 26

/ hpdtl:comp.sys.ibm.pc / brown@vidiot.UUCP (Vidiot) / 11:09 am  Jan  5, 1990 /
<In article <21990002@hpvcfs1.HP.COM> rexw@hpvcfs1.HP.COM (Rex Wickenkamp) 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?
<
<Before you ask how files can end up not having a directory
<entry, but still have space allocated in the FAT, I will try and answer that.
<The answer is:  I don't know.  I have seen programs screw up, like compilers,
<that somehow leave FAT entries there but, the directory entries are gone.

The easiest way I know of for this to happen is to have a program open a file
for output, and then end without closing it.  This will happen if, for
instance, you must kill a runaway program that has files open.

Comments about the level of robustness of the MS-DOS filesystem have been
deliberately omitted.  :-(

<-- 
<      harvard\     att!nicmad\              cs.wisc.edu!astroatc!vidiot!brown
<Vidiot  ucbvax!uwvax..........!astroatc!vidiot!brown
<      rutgers/  decvax!nicmad/   INTERNET:<@cs.wisc.edu,@astroatc:brown@vidiot>
<----------

Dan Conway
dan_conway@hplabs.hp.com