Archived from groups: microsoft.public.windowsxp.perform_maintain (
More info?)
On Fri, 1 Apr 2005 10:50:37 -0500, "Mike Hall \(MS-MVP\)"
>If Windows needs to run CHKDSK, it will tell you in no uncertain terms..
Correction: If Windows *thinks* it needs to run ChkDsk ...
>I have to say that I never deliberately run it.. never have need to do it..
>call me lucky if you will, but I do not believe in luck..
I wouldn't say lucky; just overgeneralizing from a small sample base
What's going to damage the file system?
1) Interruption of normal writes to disk
This is an eventuality that Windows has kept in mind since Win95 or
so. When a HD volume is being written to, a flag is set within the
file system for that volume, and is cleared when the volume is closed.
When the OS boots, it checks this flag; if the flag is set, it knows
that the previous session interrupted disk writes in progress. So it
does a check of the file system logic to "fix" any errors. Any files
that were being updated are either lost, or left broken.
When Win95 debuted this feature, it ran Scandisk from DOS before any
writes to the HD started, and it asked you what to do when errors were
found. Win98 does the same, but by default it "fixes" them
automatically, and throws away any recovered remnants. WinME ran the
check from Windows, where it often has to restart because the at-risk
volume is already being written to by other processes. XP hopefully
starts the process earlier than WinME, but also automatically fixes
things and (unlike Win9x) this cannot be changed.
What the above illustrates, is a move from respectful treatment of
data that puts the user in control, to a "kill, bury, deny" strategy
that sacrifices user data in the interests of reducing support calls.
2) Physical defects on the HD
This is a budding crisis you need to know about, and urgently so, but:
- CMOS settings default to disabling SMART reporting on POST
- HD's firmware auto-hides bad sectors on the fly
- NTFS's code also auto-hides bad clusters on the fly
- explicit ChkDsk /R also auto-hides bad clusters, buries results
Once again, this looks a lot like "kill, bury, deny" that may delay HD
RMA beyond the warranty period, and hides any early warning the user
might have had before the big meltdown.
HD firmware, NTFS driver code, and ChkDsk /R all "fix" areas of bad
physical disk the same way; they attempt to copy material within these
areas to "good" disk, and then change addressing so that this is used
while the bad areas are hidden from use.
HD firmware does this at a deeper level that won't show up within the
file system's data structures - indeed it has to, given that this is a
system-level fix that runs beneath all OSs.
3) Bad data written to HD; software
Now we come to things that NTFS autorepair philosophy simply assumes
will never happen, starting with soiftware crashes that garbage the
disk's contents. For example, if a bug causes the processor to enter
an arbitrary point within a low-level "write to disk" call, with
arbitrary address values, then any part of the file system structure
contents can be garbaged.
This can be deliberate, as was the case with Witty. NTFS's
much-vaunted security did nothing to prevent Witty from writing over
raw NTFS file system structures, trashing data.
4) Bad data written to HD; hardware
Bad RAM can corrupt not only what is written to HD, but where it is
written as well, having a similar effect as (3). The hardware
involved may be RAM, processor, motherboard chipset or HD logic board,
and flakiness can come from overclocking, bad cables and poor power,
including failing motherboard capacitors.
So my answer would be a bit different.
If you ever have reason to expect anything other than (1), then you
should consider it too dangerous to write to the at-risk HD, and thus
too dangerous to run Windows as that *always* writes to the HD.
http://cquirke.mvps.org/pccrisis.htm refers.
First get your data off, then consider diagnostics or recovery, and
only then consider "fixing" the file system. ChkDsk /F or /R is not a
safe diagnostic, and it is certainly not a data recovery tool!
Finally, a physically sick HD cannot be "fixed" by its firware, NTFS's
fixing-on-the-fly, or ChkDsk /R. They can only make things look
rosier, like rouging up the face of someone bleeding internally so
they don't look so pale and thus don't alarm the neighbors.
>---------- ----- ---- --- -- - - - -
Gone to bloggery:
http://cquirke.blogspot.com
>---------- ----- ---- --- -- - - - -
Facebook
Twitter
Instagram