NTFS and Dos

  • Thread starter Thread starter bahri
  • Start date Start date
B

bahri

Hi all!
I have been using WinXP for some time strictly on a Fat32 file system.
Now I shall be building a new system and would like to use NTFS file system
since many advice that it is better more secure etc.
Problem is I still use many batch files for backing up and general disk
maintenance.
Can some one guide me or point me to a place on the web where this NTFS and
DOS problem is explained properly?
Say, -- Can dos be used from a dos box with XP?
Can utilities like XXCopy and PKZip25 for dos be used in an Xp session?
I thank you all for a great newsgroup
Regards
bahri
 
Hi Bahri

Yes, you can run what looks like DOS in WinXP, whether or not you use NTFS. One way is to go to Start|Programs|Accessories|Command Prompt. Or in Start|Run, "Cmd". And, yes, I use XXCopy for backup in WinXP

What DOS won't do is detect NTFS drives and partitions. So don't expect to boot up in an emergency using a DOS floppy. It's likely that someone on this forum can tell you how to solve that problem, but it's not me

Good luck, Dan S
 
Hi!
Thanks for the info.
So When booting to dos NTFS is not seen, but during a winXP session dos
executables like Dir and find should work on NTFS.
Thanks again
Regrds
bahri
Somerset27 said:
Hi Bahri,

Yes, you can run what looks like DOS in WinXP, whether or not you use
NTFS. One way is to go to Start|Programs|Accessories|Command Prompt. Or in
Start|Run, "Cmd". And, yes, I use XXCopy for backup in WinXP.
What DOS won't do is detect NTFS drives and partitions. So don't expect
to boot up in an emergency using a DOS floppy. It's likely that someone on
this forum can tell you how to solve that problem, but it's not me.
 
On Thu, 22 Apr 2004 00:12:31 +0200, "bahri"
I have been using WinXP for some time strictly on a Fat32 file system.
Now I shall be building a new system and would like to use NTFS file system
since many advice that it is better more secure etc.

Bear in mind there's not much in the way of recovery tools for NTFS,
and no maintenance OS to host formal av scanning.

IOW, you'd better hope the security saves you from trouble, because if
trouble hits, you stay hit. Noting that NT and NTFS does absolutely
nothing to prevent Witty from trashing the HD, I'd not hope too much.
Problem is I still use many batch files for backing up and general disk
maintenance.
Can some one guide me or point me to a place on the web where this NTFS and
DOS problem is explained properly?

Command.com and Cmd.exe are command and .bat interpreters that run DOS
apps within NT. As long as these apps use the "normal" file system
API calls, they will work fine, though NTFS permissions may limit what
they are allowed to do.

But any DOS app that accesses the disk directly should not be allowed
to do so, and can be expected not to work.
Say, -- Can dos be used from a dos box with XP?

DOS commands and programs, yes, within limits above.
Can utilities like XXCopy and PKZip25 for dos be used in an Xp session?

You'd use the Win32 console version of PKZip25 instead, as this
supports Long File Names. To clarify; there are a number of command
line tools that "look like DOS" such as TFP, Ping, PKZip25 etc. that
are in fact Win32 apps that wouldn't run in DOS anyway. They will
work fine within NT (XP is version 5.1 of NT). So; yes.

What you will not be able to do is run these from a DOS or DOS mode
diskette boot, or from a Win9x GUI boot either, for that matter. The
kernel that provides the file access API must be NT.


-------------------- ----- ---- --- -- - - - -
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.
 
On Thu, 22 Apr 2004 00:12:31 +0200, "bahri"


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 ?

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.

I have never seen an NTFS file system become garbage unless the
underlying hardware failed. This would loose a FAT32 systm too. I've
heard of lost file systems but it's very very rare. I have never lost
a file due to a power failure unless the user hadn't saved it. Maybe
I've been lucky.

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. 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.

www.ntfs.com lists lots of other recovery tools and techniques.

What else do you need ?

I'd avoid all the old helper apps becasue of the nice long file names
in a modern operating system. If you insist on using some old verison
of a file manager becasue you like it, then stay with what you have.
Don't bother upgrading to anything.

Lots of games won't run on anything later than w/98, but XP has gotten
better I'm told.

None of this is an NTFS vs FAT32 issue.
 
As others have said, FAT32 or NTFS, neither way does XP do DOS. And, either
way XP will still run common DOS-like command, such as COPY, XCOPY, etc.

As for security, that is fine if you have a multi-user system, and you want
to hide some files form some people (e.g., kids). Otherwise, the best
security for a pC is a locked front door to the house.

But, NTFS does have some advantages, mostly being able to handle larger
files. FAT32 is limited to 4 Gig per file. That may seem like a lot, until
you try to make a DVD from a digital home video recorder. I have heard that
NTFS has more built-in redundancy and the ability to recover from some disk
errors. In practice, I have noticed no difference between XP with FAT32 and
XP with NTFS. If you run long nough and hard enough the file system will
start to get errors. CHKDSK will fix them. In either case, have a good
backup of all files, since the hardware could die, or a virus could attack.

But, in case you ever need it, there are non-XP routines that can read NTFS
files systems and copy files from them. One of my favorties is a read-only
driver for a DOS (win98) boot floppy, free from Systeminternals. But, a
better solution is a recovery CD, such as the one that Bart's PE builder can
make for you. Not only does it do NTFS, but USB, too.
 
None of the NT Windows systems, including XP, are based on DOS. They do,
however, have a DOS emulator that can allow you to run most DOS programs
using WinXP. I had a couple of non-DOS old programs that wouldn't run under
XP. I made a shortcut to the start file for the program, right clicked,
chose Properties.... Compatibility tab..and chose to run the program as a
Win98 program (compatibility) and it now works fine.
 
As others have said, FAT32 or NTFS, neither way does XP do DOS. And, either
way XP will still run common DOS-like command, such as COPY, XCOPY, etc.

As for security, that is fine if you have a multi-user system, and you want
to hide some files form some people (e.g., kids). Otherwise, the best
security for a pC is a locked front door to the house.

But, NTFS does have some advantages, mostly being able to handle larger
files. FAT32 is limited to 4 Gig per file. That may seem like a lot, until
you try to make a DVD from a digital home video recorder. I have heard that
NTFS has more built-in redundancy and the ability to recover from some disk
errors. In practice, I have noticed no difference between XP with FAT32 and
XP with NTFS. If you run long nough and hard enough the file system will

^^^^^^^^^^^^^^^^^^^^^^^^^

Wrong. A file system that fit this description would not be suitable
for a business system. These are frequently run hard, 24x7, litterally
for years. NTFS works.
start to get errors. CHKDSK will fix them. In either case, have a good

With NTFS your don't have to "fix" them. This is nice for a system
that doesn't have a UPS and occasionally gets a power hit.
 
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
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.
 
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.

 
You know much more about fixing FAT32 than I do. I have better things
to do. ;-)

Data loss can be a great motivator said:
As I said, it's better to avoid a corruption problem than spend
time looking for fragments. NTFS survives power failures,

False, as noted. It just kills/buries/denies with more stealth.

Think Milosovic with a better PR department ;-)
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.

IOW, it doesn't happen, if it does happen we can't fix it, but it
doesn't matter because you should have backups (blame the victim).
If a PC shows lost clusters it's got a hardware problem
and gets fixed.

Don't confuse lost cluster chains (a FATxx file system logic
derangement common when updates are interrupted) with bad clusters.
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.

Yes... a problem when it comes to hosting av from Linux to formally
clean up malware infections.


-------------------- ----- ---- --- -- - - - -
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.
 
Back
Top