Re: Comparison of NTFS/MFT recovery software?
From: cquirke (MVP Win9x) (cquirkenews_at_nospam.mvps.org)
Date: 09/05/04
- Next message: ~misty: "RE: No sound after sp2"
- Previous message: JT: "Windows installer problem"
- In reply to: Al Dykes: "Re: Comparison of NTFS/MFT recovery software?"
- Next in thread: cquirke (MVP Win9x): "Re: Comparison of NTFS/MFT recovery software?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 05 Sep 2004 18:56:58 +0200
On 4 Sep 2004 23:46:35 -0400, adykes@panix.com (Al Dykes) wrote:
>Maybe all the conditions that chkdsk /F can't fix are things that are
>impossible to fix ?
That's the arrogant assertion, sure. But the abilities of auto-fixing
tools are always pretty crummy, and generally work from a fixed
assumption base; that the only type of problem that will arise is an
interruption of sane file operations (which journalling can cope with)
>... Usenet asking if there was a document that listed every
>possible messages from chkdsk, similar to the documententation for
>fsck on any unix system, and the answer was no, why do I want one ?
Yep; the classic "why would you want that?" myopia ;-)
>Compare that to every windows98 laptop I every saw that had CHK files
>in the C root because if incorrect shutdown.
Well, that's a good case and point. Would FATxx look "better" if
Scandisk automatically deleted lost cluster chains, instead of
preserving them as .CHK?
MS seemed to think so; that's why they set Win98's defaults in
Scandisk.ini to automatically "fix" errors and delete recovered files
the "kill, bury, deny" approach to file system maintenance.
In the case of NTFS, that's exactly what happens. When transaction
logging undoes a change, what do you think it falls back to? What if
you wanted the partially-completed file update, rather than lose it?
If I add 15 bytes at offset 200 into a 200M .AVI file, do you think
transaction logging preserves the entire 200M file (so it can fall
back cleanly) and creates an entirely new copy to fall-forward to when
it's done? Leaving aside the performance impact, how would NTFS
manage that if there's insufficient free space?
MS's docs on this are clear; transaction rollback does not preserve
user data. You can't preserve data that has not been written do HD
from RAM yet; the best you can do is hand on to the bit that was
written to disk, and that's basically what .CHK files do, if you like.
The point I'm making here is:
- interrupted file operations *will* lose data
- bad hardware issues *will* corrupt file systems
- raw disk writes *can* trash file systems
There's no "magic bullet" to NTFS that stops any of these things from
happening; the second two are below the file system's layer of
abstraction, so FATxx vs. NTFS has no meaning other than to what
extent repairs can be guided by redundant information.
You might have expected NT's hardware abstraction and NTFS's security
awareness to prevent malware from writing directly to raw disk.
See Witty.
>------------ ----- ---- --- -- - - - -
The most accurate diagnostic instrument
in medicine is the Retrospectoscope
>------------ ----- ---- --- -- - - - -
- Next message: ~misty: "RE: No sound after sp2"
- Previous message: JT: "Windows installer problem"
- In reply to: Al Dykes: "Re: Comparison of NTFS/MFT recovery software?"
- Next in thread: cquirke (MVP Win9x): "Re: Comparison of NTFS/MFT recovery software?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
