What are you recovering from ?
Any type of data corruption scenario.
NTFS doesn't produce the fragments of files that scandisk does on
FAT32 systems. This is based on experience with thouands of NFTS file
systems, since about 1991 when NT was called Windows 3.5 and a pre-beta
distribution.
It prolly does, but clears them automatically so you never see them.
Let's say you are saving a 200-page document and the PC restarts at
around page 190 or so. NTFS will roll back the interrupted
transaction, irretrievably losing the fragment of saved file.
FAT32 will either find a lost cluster chain (which can be saved) or a
file size mismatch (which is typically "fixed" by truncation). Either
way, so have some chance of recovering the file fragment as raw text,
cleaning it up, pasting/saving as Word, reapplying formatting.
Don't confuse file system sanity with data recovery.
I have never seen an NTFS file system become garbage unless the
underlying hardware failed.
And if the underlying hardware fails? That happens, you know...
This would loose a FAT32 systm too.
No, it wouldn't necessarily "lose" FAT32 or NTFS. It will very likely
corrupt the file system structure and lose some data. It will make it
unsafe to run Windows, given that Windows requires a ton of files to
be unbent in order to work, and constantly writes to the HD.
I _have_ seen NT/w2k/XP systems crash and become unbootable,
frequently due to patches and updates. In all cases I have been able
to pop the disk into another machine (running the same OS and service
pack) and read the data off the disk.
Nice if you have a spare PC lying around, *and* you manage to stop it
writing to the at-risk HD (e.g. SR).
I have also booted Linux and read huge amounts of NTFS data
off the disk and copied it to a USB backpack disk or over the
LAN to another system.
It's ironic one has to learn a whole new OS just to maintain this one!
www.ntfs.com lists lots of other recovery tools and techniques.
Yes, and one of the goodies there is ReadNTFS. It's slow to populate
a directory and doesn't "remember" dirs it's been to, so you will come
to hate MS's gratuitously deeply-nested paths.
No LFNs, and no ability to highlight multiple things to copy off; it
will copy subtrees, though. For example, you can highlight and copy
off all of PROGRA~1, but if you go into PROGRA~1, you can't select and
copy off (say) MICROS~4 and MICROS~2 while leaving MICROS~1.
OTOH on FAT32, your options are wider when it comes to DOS mode
support, including the preservation of Long File Names.
A proper maintenance OS, for this as well as hosting arbitrary
antivirus etc. apps for formally clearing malware.
I'd avoid all the old helper apps becasue of the nice long file names
in a modern operating system.
Several utilities and tools can see Long File Names from DOS or DOS
mode, as long as there's no extra driver code in the way.
Effectively, that means you lose LFNs if recovering NTFS data from DOS
or DOS mode environments. Three types of LFN support:
1) LFN recovery tools
These are the best-known; in fact, until I came across some Linux
sites that covered MS OS maintenance, they were all I knew too. One
is LFNBk.exe from the MS OS CDs, which I consider too hairy to use (it
strips and re-applies LFNs). The other is a free 3rd-party
work-better called DOSLFNBk.exe, AFAIK. I don't use either.
2) LFN drivers
Just as DOS TSR drivers exist to access NTFS, so are there LFN drivers
that work on FATxx. I know of two, one of which has a nasty flaw; it
spawns non-unique 8.3 names under same-stub LFNs (e.g. MICROS~1,
MICROS~1, MICROS~1 and not MICROS~1, MICROS~2 and MICROS~3).
These allow DOS apps that can handle LFNs as per API support to see
and work with LFNs, e.g. InfoZip, Command.com, Edit etc.
3) LFN file managers
Some "Norton Commander" clones reputedly support LFNs, tho I don't
know if that support is built-in or via the API - as extended by (2).
What I use are Odi's LFN Tools, which are LFN-aware replacements for
the standard DOS commands, e.g. LDir, LCopy, LRen, LDel etc.
None of this is an NTFS vs FAT32 issue.
Not true; as above. Actually, you are right - it's not so much an
NTFS issue as it's an OS issue; without a maintenance OS to wipe its
butt, NT has to rely on good old DOS mode to bail it out.
If you know Linux and trust the reliability of reverse-engineered NTFS
support (something even Linux advocates are squirmy about) then that
makes NTFS that much easier to support; else not.
-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.