Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!ut-ngp!ayac071
From: ayac071@ut-ngp.UUCP (William T. Douglass)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Beward: chkdsk /f
Message-ID: <5698@ut-ngp.UUCP>
Date: Sat, 25-Jul-87 12:20:56 EDT
Article-I.D.: ut-ngp.5698
Posted: Sat Jul 25 12:20:56 1987
Date-Received: Sun, 26-Jul-87 01:45:43 EDT
References: <1333@chinet.UUCP>
Reply-To: ayac071@ngp.UUCP (Bill Douglass)
Distribution: na
Organization: UTexas Computation Center, Austin, Texas
Lines: 44
Keywords: back-ups DOS chkdsk PC
Summary: Moral: Make back-ups.

In article <1333@chinet.UUCP> ward@chinet.UUCP (ward) writes:
>Be aware that there is a "characteristic" of CHKDSK /F that you may not want.
>  Background: when DOS encounters a 00 byte at the front of a directory entry,
>it assumes the rest of the directory is empty.  For example, disk-reorg 
>programs will pack all the active files to the front of the directory, then
>zero all the remaining entries.  This speeds up disk access.
>  CHKDSK ALSO makes this assumption: that if it finds a 00 as the first byte
>of a directory entry, it assumes the rest of the directory is empty.
>  Situation that can cause problems:  a program goes bonkers, and writes some
>garbage into your DIRECTORY.  Among that garbage, is a 00 at the front of
>a directory entry.


Note that any program writing haphazardly into a directory list (be it root or
a sub-directory) is apt to cause more trouble than just that.  Corrupted file 
names, invalid file sizes and attributes are potential outcomes of such an 
incident.  Also, I would be concerned about the integrity of the FATs' after 
an event like that.

>  Result: CHKDSK /F will find the entries in the file allocation table for
>all the files that FOLLOW the 00 byte, but won't find the files in the
>directory!  As such, it will create file after file (filennnn.chk) for the
>files that "are actually good".

What do you mean "actually good".  DOS sure can't find them; a DIR command
will verify that the OS considers the directory empty.  Given the above format
for directory entries, I consider CHKDSK's action to be the only reasonable
approach to take.  You data is restored, but with in a different directory with
different names.  You have the task of copying the files back.

>  Always DISKCOPY a diskette before doing chkdsk /f - it could save you
>problems.  On a hard disk, run it without the /f and be sure the disk is not
>"too trashed" before trying again with /F.  If CHKDSK reports lots of lost
>files, be aware it could be because a 00 byte got into a directory
>incorrectly.

I would go further: as possible, back-up your data.  Especially for Hard
Drives, but also floppies.  Then you are in a position to recover from 
corrupted directories, invalid FAT's, lost sectors etc.  Especially critical
if you plan on using untested programs (like d/l's from BBSes or the net.)

Bill Douglass
ayac071@ngp.UUCP (or whatever)