ward@chinet.UUCP (ward) (07/25/87)
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. 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". 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.
ayac071@ut-ngp.UUCP (William T. Douglass) (07/25/87)
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)