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)