Means no C:\NTLDR is present. Boot the correct-version NT CD, choose
Recovery Console, and enter the FixBoot command.
(correct advice to fix Win9x snipped, as this is NT)
If you have XP with a fat32 system all I can say is, WHY?
Because:
1) I may not need NTFSs features
2) I may prefer to avoid NTFSs performance overhead
3) I may prefer not to be locked out of my data one day
4) I may prefer to clean malware than format and rebuild
5) I may wish to preserve ability to recover data from sick HD
6) I may wish to manually repair file system with less data loss
In fact, for consumerland (no backup management, exposure to malware)
the question may be: Why would you risk using NTFS?
Let's run through these in turn...
1) I may not need NTFSs features
Per-user permissions at the file system level aren't useful if there's
only one user who owns the system and wants untrammeled access to all
files at any time. 3rd-party encryption that is not tied to OS of
file system version may be preferable. Journalling simply means
throwing data away to fall back cleanly to the previous state, so
that's not a magic bullet for data safety either.
2) I may prefer to avoid NTFSs performance overhead
YMMV here, because NTFS can boost performance as well as reduce it.
Specifically, NTFS manages large numbers of files in a single
directory better than FAT (due to B-tree indexing rather than
flat-lookup) and as it stores small files entirely within the
directory metadata, access to these can be faster too.
But for large files (e.g. video editing), these benefits don't apply -
and the extra navel-gazing imposed by NTFS's security slows things
down, without any benefits to offset this.
3) I may prefer not to be locked out of my data one day
NTFS is as fragile as FATxx when it comes to problems arising below
the OS level of abstraction. Both flaky hardware and pre-file-system
malware don't care which raw sectors are part of protected file system
structures or not; everything is equally likely to get splatted.
When file access hinges on a password or encryption key, the file can
be lost due to damage to where these are stored, as well as the file
itself and the file system structure that supports it.
By default, security settings can block you from accessing your own
files. For example, the Recocvery Console is usually postulated as
the maintenance OS replacement for DOS, but unless you set things in
advance, it won't copy from volumes other than C: or support the use
of wildcards such as Copy *.* - and as it is not an OS (cannot run
arbitrary programs) you can't use a file manager as a fix.
If the NT installation is botched to the point that RC cannot see or
query it, then you can't access your data from RC at all.
4) I may prefer to clean malware than format and rebuild
The only OS that can be trusted to read and especially write to NTFS
is NT, and NT only runs from the HD. Malware that infects NT may make
it impossible to clean, if even Safe Mode runs the malware and the
malware is smart enough to defent itself.
RC is not an OS, and cannot host antivirus software. MS's hard-to-get
PE disks, as well as third-party alternatives, work by running NT from
a bootable CDR, but these have significant limitations; av software
that needs to be installed can't be, DOS apps may not be supported,
anf the registry that is visible is the irrelevant one on the boot CD,
not the one on the system that needs to be malware-cleaned.
5) I may wish to preserve ability to recover data from sick HD
With no maintenance OS and the dead-by-default RC, there's nothing to
host data recovery tools (if indeed you can find such tools).
Dropping the HD into another NT system to read it is fraught with
peril, due to possble cross-talk between the installations (some
namespace objects mapped by CLSID or Desktop.ini are path-oblivious),
risk of unsolicited writes to the at-risk drive (e.g. XP's SR), and
risk of auto-upgrading of the NTFS file system or encryption scheme to
versions the HD's host installation won't be able to read.
6) I may wish to manually repair file system with less data loss
NT's file system maintenance tools (or should I say, tool) are
pathetic; ChkDsk's user non-interface dates from DOS 3.3 and should
have been buried long, long ago. Even in the DOS 6 era, it was
considered unfit for use; runing ChkDsk on these systems tells you
that Scandisk is better and suggests you use that instead.
ChkDsk has no interactive mode - i.e. it will not stop, tell you what
it's found ("your Windows directory is invalid"), tell you what it
plans to do about it ("The invalid directory will be deleted") and ask
you whether it should do this or not.
"ChkDsk (without parameters) is safe; it won't fix anything" -
however, transaction rollback may be automatic even if you run ChkDsk
in this safe mode, or simply start NT and it "fixes" this on startup.
Have a bad exit at the end of saving a 500-page .doc that could have
been recoverable as .txt, and it will be destroyed by rollback.
ChkDsk (without parameters) is unreliable when the volume it is
checking is "in use". As most PCs have one big doomed C: which is
always "in use" by Windows, this makes the "safe" form of ChkDsk
almost useless unless set to run on startup, or from an RC boot.
ChkDsk /F (and the surface-scanning /R option) will not only
automatically "fix" errors without asking first, it won't even tell
you what it's done. If you really want to know, you'd have to scratch
in the bowels of the even logging system for the report.
As only NT can safely read and write NTFS, and NT has to run from HD
(massively dangerous if the HD is at-risk), your choice of alternate
data recovery tools is likely to remain limited.
--------------- ----- ---- --- -- - - -
Dreams are stack dumps of the soul
