NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/msdos/misc/6728

Text File | 1992-12-28 | 5.2 KB | 111 lines

Newsgroups: comp.os.msdos.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!phoenix.Princeton.EDU!bathurst
From: [e-mail] (Bruce Bathurst)
Subject: Re: What to do with file0000.chk?
Message-ID: <[e-mail]>
Originator: news@nimaster
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: phoenix.princeton.edu
Organization: Princeton University
References: <[e-mail]> <[e-mail]>
Date: Mon, 28 Dec 1992 06:17:11 GMT
Lines: 97

In article <[e-mail]> [e-mail] (Edward Wong) writes:
>>>>>> On 14 Dec 92 19:43:04 GMT, [e-mail] (KUN YU) said:

[SNIP]
>->  the machine. CHKDSK showed lost chains, I used chkdsk/f to recover
>-> them into files. But when I type file0000.chk, sometimes I can see some
>-> binary codes, sometmes I got "error reading drive C" message. No bad sector
>-> is show on chkdsk.

>-> Does that mean file0000.chk is on bad sectors? If true, would  keeping the
>-> junk file there prevent getting into the bad sectors?

>I don't think there is any use for the file that is recovered by chkdsk.
>When the computer checks for data consistency, these data appear at places
>where they shouldn't.  So, the computer has to get rid of it.  the
>file????.chk just link all the problem blocks together and name it
>file????.chk, you can do whatever you want with it.  I would just delete
>it.  But it's up to you, some people may find it useful in some way.

If it's huge, it probably is the WINDOWS swap file, and you needn't
worry.  Yes, you're right that file0000.chk will protect a bad sector.
This is too much of a coincidence, though, unless someone tripped over
the power cord.  Many error messages are spurious and just mean "I'm
not well!".  I ad backup repeatedly abort on one bad sector, and
CHKDSK and the Norton Utiities repeatedly reported nothing wrong.  One
surface scanner paused at the sector, but moved on after it passed an
acceptably small number of read attempts.  I had to run the scanner all
night to flag the block.  Can't we have more professional tools?

My suggestion of what to do with FILE0000.CHK is to try to identify
each lost piece and repair the file.  If more than one file is
damaged, it may not be worth the effort to reconstruct the files; it
requires a sector editor such as the Norton Utility Editor, some
understanding of disks, and time.

You have written the lost pieces on the disk as separate files for two
reasons: you must identify the original file they belong to, and you
must try and reattach them by using the COPY command.

The Procedure

1. Identify the original files that FILE0000.CHK belongs to.

Today, virtually every file is binary and cannot be read with "type",
"edlin", or "edit".  Microsoft apparently expects every homeowner
(with a computer on his or her desk) to dump the files in hexadecimal
with the DEBUG command.  "Type" is potentially dangerous, and I
suggest you consider investing $15 in Buerg's LIST program.

"It's my novel!"

2. If CHKDSK wrote several files, all fragments of one original file,
place the several files in the proper order.  If you defragment your
disk daily, you will have few files to examine.  If you have only one
lost "chain of clusters" (contiguous pieces), repair is a snap.

"FILE0000.CHK  FILE0002.CHK  FILE0001.CHK"


3. Repair your novel by appending these binary files in their correct
order.

"Copy NOVEL.WP  BLIP.WP"
"Copy BLIP.WP + FILE0000.CHK + FILE0002.CHK + FILE0001.CHK  OHPLEASE.WP"


4. Try and load the resulting file into  your application and check it
for accuracy.  If it won't load, or pieces are missing, return to step 2.

To open a file means to copy the instructions for finding its pieces
on the disk into memory and update these instructions in memory only,
though the data is written to the disk.  Closing a file means writing
the instructions to the disk.  One power blip when a file is open and
the instructions for finding everything written since the file was
last closed is lost, though the data is on disk.

FASTOPEN is an instruction killer, as is BREAK ON and "Abort, Retry,
Fail?"  BREAK ON, in addition, kills data being written to disk.

P.S. I adjust friends' PC's so CHKDSK is run during a SHUTDOWN.BAT
command, and any orphaned clusters are saved to a directory called L&F
(after UNIX's lostandfound).  Sometimes this requires moving the files
from \root with a MOVE command that doesn't change the file's position
on the disk.  The AUTOEXEC reports the number of file fragments stored
in \L&F, and runs a fast disk defragmenter, such as "the DOG", if no
unresolved fragments are present. In particular, the SHUDOWN.BAT
flushes the cache (if not write-through), closes all files with an
equivalent of the UNIX sync command, runs CHKDSK, and parks the hard
drive (I'm old-fashioned).  The press of a key pops one back to the
home directory (never \root, the directory most sensitive to damage).
Preventive medicine is the best cure.

Bruce (Gypsy Scholar)
--
Department of Geological and Geophysical Sciences
Princeton University, Princeton, NJ 08544
[e-mail] [e-mail] !princeton!phoenix!bathurst