Re: NTFS and Dos

From: Al Dykes (adykes_at_panix.com)
Date: 04/23/04 

Date: 23 Apr 2004 12:10:15 -0400

You know much more about fixing FAT32 than I do. I have better things
to do. ;-) As I said, it's better to avoid a corruption problem than
spend time looking for fragments. NTFS survives power failures, and
if an employee types "a 200 page document" autosave will always have a
copy good to the last few minutes in some temp directroy (at least for
any office suite I'm familiar with). No need to look for file
fragments. If a PC shows lost clusters it's got a hardware problem
and gets fixed.

As for my reference to using Linux to recover from
an unbootable system disk, I never proposed using Linux to
write to an NTFS file system. That's not quite ready yet.

In article <mgei80dnqcdhlr019l1f9fi12d0sjbi3a9@4ax.com>,
cquirke (MVP Win9x) <cquirkenews@removethis.mvps.org> wrote:
>On 22 Apr 2004 10:26:49 -0400, adykes@panix.com (Al Dykes) wrote:
>>In article <2lhf80hjfmm9t1gvk9djiv228drg2v7h8i@4ax.com>,
>>cquirke (MVP Win9x) <cquirkenews@removethis.mvps.org> wrote:
>
>>>Bear in mind there's not much in the way of recovery tools for NTFS,
>>>and no maintenance OS to host formal av scanning.
>
>>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.
>
>>What else do you need ?
>
>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
>***, 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.
>>-------------------- ----- ---- --- -- - - - - 

-- 
Al Dykes
-----------
adykes  at p a n i x . c o m