I understand that NTFS is supposed to be more reliable than FAT32.
Why is that ?
Does it protect better against power failures when defragging or accessing files or head crashes etc.,
or does it merely make it more difficult for the user to alter important files.
More the former then the latter. Security settings have nothing to do with a file-system's reliability. In fact in many ways it can detract from it.
When the mains failed my laptop continued to run on battery and I achieved a controlled shutdown,
but the external drive using external Mains power shut down instantly.
Although no files were being accessed, the Event Log captured FTDisk Errors.
FTDisk
warnings, not errors. An Error would result in a blue screen and the NTFS_FILE_SYSTEM or FAT32_FILE_SYSTEM (obviously depending on the filesystem in question) STOP code.
Generally speaking- there is absolutely no reason to go spelunking in the Event Viewer, and even less reason to create conclusions based on it's contents. All of my Windows machines' Event Viewers are riddled with what EventVwr describes as "Errors" but I've yet to have any real problems. The only Problems that most people have with regards to event viewer is when they try to take a "corrective action" against something in it. Then they cause problems. The EventViewer is intended to supplement additional data after a problem has already been identified; It answers "why" questions when you already know the "what". Trying to look through the eventvwr just to see if there is a "what" will cause you to see "What's" everywhere; for example, just because there is a event viewer entry labelled as Critical or "error" doesn't mean it needs your attention. If that was the case, you would have been told by a dialog box or balloon.
Basically: Any Event Log entry that doesn't have a corresponding visible element (such as a blue screen or dialog box, or balloon) is largely irrelevant and not worth worrying about. With FTDISK errors of the form "Delayed write failed..." usually it just means that you will lose a bit of data. NTFS is fault tolerant in that in keeps a transaction log; in the case of FTDISK errors that say "failed to flush the transaction log... Corruption may occur" or something to that effect, the extent of said corruption would me the loss of some recent writes. a Chkdsk will fix these errors and bring the filesystem back to perfect health, assuming any problems result from this at all.
I have also seen FTDisk errors when Acronis v 11 dismounts an image file,
in fact once Acronis has mounted an image an FTDisk error is guaranteed unless it remains mounted until Windows is shutdown.
See above paragraph for why reading meanings into Event viewer entries is a bad idea.
Would those FTDisk Errors have happened for both FAT32 and NTFS partitions on the external drive ?
I think so. They might have different labels and/or descriptions (FAT32 doesn't have a transaction log) but the jist will be the same.
Does such an FTDisk Error have more serious consequences to FAT32 than NTFS files.
Neither have any consequences whatsoever. That's why they are in the event log. They aren't issues, but they are logged because they are noteworthy. One way to think of it is as the computer's diary; it writes about interesting things that happened, "I couldn't write to the disk again, I think she's playing hard to get" type stuff.
My non-admin daughter can no longer use a BAT script that updates an INI file in this partition.
I plan to use CACLS to allow all users FULL control of the folder that holds the INI files.
I would appreciate advice upon the Inherit options CI, OI, and IO.
BIG QUESTION :-
If I give her full access to the entire partition H:\,
will that degrade disaster immunity down to the level of FAT32.
No. the "disaster immunity" of NTFS and FAT32 are the same, which is to say, virtually nil. "disaster immunity" only comes in one form. Backups. relying on the file systems error recovery or the duplication in a RAID array is foolish and asking for trouble.
I had 6 off NTFS plus 3 off FAT32 partitions on my 160 GB laptop HDD.
I launched Partition Wizard and closed all other applications to tweak a non-system partition.
I clicked the final "Apply" and achieved the ultimate finality - I lost all 9 partitions.
Was this the built-in Partitioning tool? If Not, No idea what you are talking about (as in, never used the program). Sounds like a badly designed program in that case. In the former, it was probably a mis-click... I had a similar "problem" whereby I lost three years of work on an internal drive while attempting to fix another unrelated external.
More recently I have run chkdsk on the largest partition, 47 GB of FAT32, and it found 100 KB of lost clusters
I have never seen lost clusters from a NTFS partition.
Does NTFS use clusters like FAT32, or does Chkdsk not test for them,
or does NTFS have tighter control over its clusters ?
NTFS has transaction logging and USN journalling. This pretty much obsoletes lost chains/clusters.
A lost cluster is a location on the disk that is allocated, but never actually referenced. (by a file). a file is stored in units called clusters; FAT32 has clusters of different sizes depending on the size of the disk. NTFS is almost always 4K. Either way, a cluster is the smallest unit of data you can store on a disk. If you store a 1 byte file, it takes up at the very least a single. On your average NTFS drive, a 1 byte file occupies 4KB on disk. You can see this in action. Create a file; and then view the properties. the "Size on disk" item will be a multiple of the size of the clusters on the disk the file is stored on. (well, unless you compress or encrypt the file). With Fat32, these were tracked essentially as a chain; one cluster would point to another cluster which would point to another until nothing is pointed at (at which point, it's the end of the file). a Lost chain is when a disk error or write error causes, either the "next cluster" pointer to become null on a cluster (thus making it the end of the file) or when errant writes create allocated clusters that aren't associated with files. Chkdsk determines if a cluster is associated with a file by following every file and seeing if any file uses it; to do this, it looks up the file in the directory (which holds a pointer to the first cluster of data of said file, and then follows that chain until the chain ends. If there are clusters that are never passed using this method, they are lost clusters. If clusters are passed over twice, then you have "cross-linked" clusters, which is similar to lost chains, except instead of having no file referencing the data, there are two (or sometimes more) files referencing it. Generally, only a single one is correct; editing any one of the other files can and usually will change the contents of the other files (since they effectively "share" their contents.
Anyway, I'm not sure how NTFS does it; it's still possible to get lost chains/clusters, but it's more robust against them. It doesn't matter much anyway.
If I give all users full control over H:\ will that increase its vulnerability to lost clusters ?
No.
