Good decision! On a day-to-day basis, you probably won't notice any
difference at all. After a while, though, you'll realize that you haven't
had any lost clusters or bad allocation units since you switched, and you
haven't needed to run ChkDsk very often, or at all.
Maybe you'd want to know a bit more about why that is.
There are broadly two problems; those that afflict file system logic,
and those related to the actual disk surface.
Since MS-DOS 6, Scandisk has been used as the tool to address both
problems. First, it checks disk logic, and stops when it finds errors
to ask you waht to do about them (with a "more info" to tell you what
it's planning on doing). Then it can optionally check the surface of
the disks for errors as well.
Before Scanisk, ChkDsk was used instead. This doesn't ask you waht to
do; it either does nothing and reports what it finds, or "fixes"
everything without offering you the chance to back out.
NT split off before MS-DOS 6 when ChkDsk was the norm. To this day,
NT (Win2000, XP) lack an interactive ScanDisk, providing only ChkDsk.
If you are on FATxx., you can use a FAT32-aware Win9x DOS mode's
Scandisk from DOS mode; if NTFS, you're stuck with ChkDsk.
AFAIK, it was the original Windows 95 that started automatic disk
checks following bad exits or surface defects. It works like this; a
pair of flags exist for each volume, and if one or other of these is
set when Windows starts, Scandisk automatically checks the file system
and possibly surface too.
One flag is set when file operations are in progress and cleared when
done; if still set at boot time, a "bad exit" happened and a logic
check is performed for that volume.
The other flag is set whenever an attempt to access disk fails; if set
at boot time, a logic and surface check is done on all volumes that
reside on that physical hard drive.
Over the years, the default settings for automatic Scandisk have
become more geared to reduce support calls than protect your data.
Initially, the automatic Scandisk would prompt, but the Scandisk.ini
in Win98 changed the default to auto-"fix" without prompting and
delete recovered file flargments (lost cluster chains). WinME did
away with Scandisk.ini's detailed control and uses a single checkbox
that tesds to revert to the same auto-fixing default.
XP's even more cavalier; in fact, you cannot set the AutoChk to check
for errors without fixing them automatically. It's either trust it to
"fix" without prompting (and it doesn't pause at the end to show you
what it'd done, either) or (with some difficulty, i.e. RegEdit)
suppress the auto-checking facility altogether.
So far, everything I've mentioned applies equally to FATxx and NTFS;
the variations are those between OSs, and NTFS loses out only because
you can't use Scandisk to interactively control what gets "fixed".
But the trend to "fix" the file system even if this loses data
continues within NTFS itself. The good news is that NTFS formalizes
the process of rolling back interrupted transactions to the previous
state; the bad news is that this happens automatically, and may happen
even if automatic checking (AutoChk) is disabled.
MS's own documentation on NTFS is very clear on this: NTFS rollback
does NOT preserve user data. What it does is maintain file system
integrity. If you glitched the end of saving a 500-page Word .doc
you'd have preferred to recover as broken text, too bad; it's gone.
NTFS also "fixes" surface errors on the fly, much as the modern HD
does internally, rather than only when you electively do a surface
check. Once again, the results are buried in the NT logging system,
and not exactly waved in your face as an alert.
So yes - you will see less smoke, but the fire's still there.
In fact what you may notice is data simply vanishing after it's been
"fixed" (rolled back) or a sudden HD collapse without any "you have
bad clusters" warning. The latter can happen anyway, but there's a
real risk that NTFS can mask warning signs when failure is gradual.
You'll note I always put quotes around the word "fix". That's because
logic errors are detected by a divergence of different information
items that describe the damaged file or directory, and the "fix" has
to guess which one to choose. Some errors will always result in data
corruption (e.g. cross-links) whereas others may or may not, depending
if the fixer guesses right. Either way, the cue that marked the file
or directory as damaged is lost - that's why it's so important to see
what these processes do, and keep an accessible log thereof.
When it comes to surface defects, the situation is more serious. A
failing disk is a crisis waiting to explode (given that the HD's own
internal defect management is already hiding newly-developing
defects), so "out of sight, out of mind" is a really bad idea.
Not all file system errors are the result of interruption of normal
file operations, as is typically assumed by repair tools. Bad
hardware is equally likely to currupt FATxx as NTFS; it's a problem
that isn't amenable to "fixing" by designing the file system
differently, unless it's to add extra redundancy.
By the same token, malware that writes "under" or "through" the file
system can destroy data in ways that file system design is powerless
to fix. Witty has demonstrated that raw code malware can indeed trash
raw disk, irrespective of NTFS's much-vaunted "permissions" etc.
Because NTFS cannot be read from DOS mode, you can't use DOS-based
virus scanners to formally clean NTFS volumes. Bart's PE Builder
provides bootable XP on a CDR, and there are bootable Linux CDRs that
can access NTFS too. But while there are three free or
free-for-evaluation DOS-based av, I know of none that will operate
from a Bart PE or Linux boot disk.
So you had better hope NTFS wards off traditional malware infection,
because cleaning it up may be tricky or impossible. I see far too
many "just wipe and start over" advice posts in response to "my XP is
infected!"; this should not be the only recourse, and isn't, in Win9x.
To clarify a phrase used often when discussing this subject, we don't
"create a FAT32 partition". We create an unformatted volume (a primary
partition or a logical drive in an extended partition), using either FDISK
from MS-DOS or WinXP's Disk Management. The volume is assigned a "drive
letter" even before it is formatted. At this point, it is neither a FAT32
volume nor an NTFS volume. Format.exe from Win9x/ME can format it as FAT32
and make it into a FAT32 volume. Disk Management can format it as NTFS or,
only if it is not larger than 32 GB, as FAT32. (Why the 32 GB limit? Just
because Microsoft designed WinXP that way.)
MS seems to have deliberately broken the product to push it's own
agenda. It's not as if the formatter refuses to format a FAT32 > 32G,
by saying "XP Cannot Format FAT32 > 32G". Nope; it starts formatting
away, screwing up whatever was there as formatting does, and after
taking time to get to 32G, it fails with a "too big" error.
Needless to say, this wasn't fixed in SP1, and needless to say, I
regularly see advice posters extending the misinformation that it's a
defect of FAT32 that XP can't format > 32G as FAT32.
We often say we "create a FAT32 volume"; it's convenient shorthand and most
experienced users know what we really mean, but we need to remember the way
it really happens. First we create an unformatted volume and then we format
it, at which point it might or might not become a FAT32 volume. Instead of
saying that "WinXP cannot create a FAT32 volume larger than 32 GB", we
should say that "WinXP cannot format as FAT32 a volume larger than 32 GB".
Yes, we're "splitting hairs", but if those hairs don't get split we wind up
with misunderstandings and misstatements like those in this thread.
Yep. OTOH, when creating a primary partition of logical volume on an
extended partition, one has to specify the file system - and an
appropriate boot record is created. But until the volume is
formatted, the file system is invalid.
Primary partitions contain one volume, which effectively "is" the
partition. So it's meaningful to speak of FAT32, FAT16 or NTFS
primary partitions. Extended partitions are different; they can
contain anything from none to numerous logical volumes, and those
volumes can be a mixture of FAT16, FAT32 or NTFS.
BING can create and format in one swell foop, and can skip the surface
testing altogether (so you can do that later via other tools). Nice.
--------------- ----- ---- --- -- - - -
Who is General Failure and
why is he reading my disk?
