But first, a word from our sponsor, O'Reilly & Associates...  
WebBoard, Web conferencing system software from O'Reilly 
------------------------------------------------------------------------

NTFS File System Redirector for DOS/Windows V1.1 (read-only) 


------------------------------------------------------------------------

Copyright (C) 1996, Mark Russinovich and Bryce Cogswell 
Last updated June 4, 1996 
NTFSDOS.EXE is a network file system redirector for DOS/Windows that is 
able to recognize and mount NTFS drives for transparent access. It makes 
NTFS drives appear virtually indistinguishable from standard FAT drives, 
providing the ability to navigate, view and execute programs on them 
from DOS or from Windows, including from the Windows 3.1 File Manager 
and Windows 95 Explorer. 
Please read this entire file before contacting us for help. 

Click here to
download NTFSDOS.ZIP


Here is sample output from an NTFSDOS session under DOS 7.0 (Windows 
95): 
C:\ntfsdos>ntfsdos

NTFS File System Redirector for DOS/Windows V1.1 (read-only)
Copyright (C) 1996 Mark Russinovich and Bryce Cogswell

Initialized 500KB of XMS cache.

Mounting NTFS partition(0x80:3) as drive: H

C:\ntfsdos>h:

H:\>dir

 Volume in drive H is ntfs
 Directory of H:\

EMACS          <DIR>        03-16-96  8:31a emacs
FILEMON        <DIR>        04-18-96  3:30p filemon
               <DIR>        05-01-96  1:20p newlongfilename
NTICE          <DIR>        03-30-96  8:18a NTICE
PAGEFILE SYS    28,311,552  04-07-96 12:16p pagefile.sys
PROGRA~1       <DIR>        03-30-96  5:20a Program Files
RECYCLER       <DIR>        03-30-96  5:36a RECYCLER
TEMP           <DIR>        05-15-96 12:58a temp
USERS          <DIR>        03-16-96  3:27a users
WIN32APP       <DIR>        03-16-96  3:27a win32app
WINNT          <DIR>        03-30-96  8:41a WINNT
WINNT35        <DIR>        05-15-96 12:58a WINNT35
         1 file(s)     28,311,552 bytes
        11 dir(s)     388,284,416 bytes free

H:\>


Contents of the Package

  *	README.TXT - this readme 
  *	NTFSDOS.EXE - DOS/Windows NTFS file-system driver 
  *	NTFSHLP.VXD - helper VxD needed only for long filename support in 
	Windows 95 

Security Implications

NTFSDOS raises some obvious questions about NT security. However, 
Microsoft's claims for NT security assume physical security. In a white 
paper "Windows NT File System: Built for Data Security", Microsoft 
denies that NTFSDOS has any implications for NT security: "Despite 
reports, this utility does not affect the ability of the Windows NT 
Server operating system to secure critical business data. The 
availability of this utility does, however, underscore one of the most 
important and fundamental necessities of network security the need for 
physically securing server hardware." Uh, okay, if you say so.
The PC Week (April 29, 1996) article mentioned in the Microsoft white 
paper was a small notice, "Utility threat to NT file system security", 
which said: 
Two University of Oregon faculty members released an NT File System 
redirector for DOS and Windows that potentially provides an easy route 
to compromising NT security.
The utility, which is available at  
ftp://ftp.ora.com/pub/examples/windows/win95.update/schulman.html, makes 
NTFS files visible in the DOS/Windows File Allocation Table. The 
potential leak occurs when someone boots an Intel-based NT server from a 
DOS floppy, then uses the utility to read the NTFS. 
Computerworld Australia (May 17, 1996) carried a lengthier article on 
NTFSDOS, "Cracks exposed in NT's security". A copy of this interesting 
article was posted by an OS/2 supporter to bit.listserv.os2-l: 
[NTFSDOS's] ability to pick the locks on NT's file management system 
will shock large sites into a more realistic view of NT security, 
predicted Dr. Ian Graham, PC development manager at data security 
company, Eracom. Graham claimed many large sites, Including Australia's 
financial institutions, have put too much trust in NT workstation 
protection.
The appearance of NTFSDOS might correct that by graphically 
demonstrating they've enjoyed a false sense of security, he said....
Microsoft Australia marketing manager for NT workstations, Peter Moore, 
said that the reports underscore the need to apply basic corporate 
security precautions to PC networks. 

Enhancements over V0.9


NTFSDOS V1.1 has been greatly improved over V0.9. Some of the changes 
include: 
  *	Drives are now accessible under Windows 3.1 
  *	Long filename support under DOS 7.0/Windows 95. NTFSDOS can now mount 
	and access NTFS drives that have no short-file names. 
  *	Compressed files and directories. NTFSDOS understands the NTFS 
	compression format so compressed files can be accessed transparently. 
  *	Instancing under Windows. Now you can open multiple DOS boxes under 
	Windows, each with different NTFS drive current directories. 
  *	Redirector bugs fixed. NTFSDOS drives look to DOS and Windows exactly
	 like local FAT drives. This means you can view and execute any files, 
	such as bitmaps, Windows and DOS programs, that you would be able to on 
	FAT drives, from Filemanager, Windows 95 explorer, or the DOS command 
	prompt. 
  *	Greatly improved performance in directories with 100's of files. 
  *	Drive detection fixed. NTFSDOS no longer confuses HPFS drives for NTFS. 
  *	Uses XMS instead of EMS. This alleviates the need for EMM386 to be 
	running for NTFSDOS to have a large cache. 
  *	Many minor bug fixes. NTFSDOS is now extremely robust. 
  *	Prevents itself from being run twice.

Installation and Use 


To use NTFSDOS, simply execute it from the DOS command line (DOS 5.0 or 
greater is required), or from your UTOEXEC.BAT. Executing NTFSDOS before 
Windows is started will create NTFS drives that are visible globally 
once inside Windows. Executing NTFSDOS in a DOS box means that the NTFS 
drives only exist within the DOS box where NTFSDOS was executed. 
When NTFSDOS starts, it will scan all hard-disk partitions on your 
system to look for NTFS drives. It will mount all NTFS drives it finds 
as unique DOS logical drive letters, and will inform you as it does so. 
If you run NTFSDOS under DOS 7.0, NTFS drives will support long filename 
calls even before Windows starts. To propagate this support into Windows 
95, NTFSDOS automatically has Windows run the NTFSHLP.VXD VxD device 
driver. No changes to SYSTEM.INI or the registry are necessary for this 
to occur - NTFSDOS will detect when Windows 95 starts and load the 
driver without user-intervention. You need NTFSHLP.VXD only if you will 
be running NTFSDOS with Windows 95. 
NTFSDOS implements its own caching, and uses one of two types of memory, 
depending on how your system is configured. Its first choice is to use 
XMS memory for caching, as this minimizes demands placed on conventional 
memory. If you start NTFSDOS before Windows, then HIMEM.SYS, which can 
be found in the WINDOWS directory under Windows 95 or the DOS directory 
under Windows 3.1, or its equivalent, must be started before NTFSDOS. If 
NTFSDOS does not detect an XMS server, it will resort to allocating 64KB 
of conventional memory for its cache. In either case, it will inform you 
of its action. 
There is no way to unload NTFSDOS from memory once it has started. 

If You Have Problems Running NTFSDOS


Accessing an NTFSDOS drive causes a hang or crash 
NTFSDOS does not support disk striping. Further, it cannot handle drives 
that are on partitions extending beyond the 2GB boundary, or that are 
larger than 2GB in size. The latter restrictions are due to limitations 
in disk BIOS code that prevent it from addressing sectors 2GB or more 
from the start of a disk. 
NTFSDOS has not been thoroughly bullet-proofed against corrupt NTFS 
drive data structures, so it may cause Windows to crash or hang when it 
runs into problems. To insure that a crash or hang is due to a problem 
with NTFSDOS rather than your NTFS drive, be sure to chkdsk the drive 
from Windows NT and try NTFSDOS again. 
Starting programs or loading files seems very slow 
Access of large compressed files may be noticeably slower than of their 
non-compressed versions. 
File times are not correct when running under DOS 7.0 without Windows 95
 
This problem is due to the fact that NTFS and LFN FAT time stamps are 
stored in Coordinated Universal Time (UTC), which is based on Greenwich 
Mean Time, and Windows 95 automatically converts times stamps returned 
by LFN calls to local time. Since local time zone information is not 
accessible outside of Windows 95, running NTFSDOS under DOS 7.0 without 
Windows 95 results in the display of unadjusted times. 
Programs complain about not being able to find files when they are there
 
A directory listing of files that have no short filename will result in 
the short filename field of the listing being blank (see the file, 
"newlongfilename," in the sample listing above). Changing the current 
directory to a path where any component of the pathname does not have a 
short filename will result in all short filename calls failing while in 
the directory. This makes most Windows 3.1 and DOS programs and many DOS 
commands (e.g. MORE) inoperative in these directories. However, LFN 
calls are supported in these directories. 
Data read from a file appears to be corrupt 
Since this work is based on reverse-engineering rather than official 
Microsoft specifications (which are reportedly available under special 
circumstances for large amounts of money), we do not guarantee data 
integrity of NTFSDOS drives. This is especially important if you are 
considering using NTFSDOS as a file backup utility. 
Files or directories seem to be missing 
Remember that files and directories that were created with no DOS 8.3 
short filenames will not be visible if you are running DOS versions 
earlier than 7.0. 
You get the message "No drive letter to mount NTFS partition..." 
If NTFSDOS complains that it cannot mount a drive because there are no 
available drive letters, you must find the line in your CONFIG.SYS that 
begins with "LASTDRIVE=". If you do not find one, then add one. Set the 
LASTDRIVE variable to a letter that is greater, by the number of NTFS 
drives on your system, than the largest drive letter you normally have 
under DOS/Windows. For example, if the highest drive letter normally in 
use is E: and you have two NTFS drives, set LASTDRIVE to G: with a 
statement in CONFIG.SYS like: 

LASTDRIVE=G: 


If you still get the message then increment the letter and try again. 
Remember to reboot after every change to CONFIG.SYS. 
You get the message "Could not allocate XMS or conventional cache" 
Memory usage on your machine is so high that NTFSDOS could not allocate 
64KB for a conventional cache. Try removing unnecessary TSRs and drivers 
and/or running a DOS memory optimizer or manager. 
XCOPY does not work in a DOS box 
XCOPY will not work on NTFS drives that are mounted in DOS boxes under 
Windows 95 (e.g. running NTFSDOS in a DOS box). This is because you 
cannot run Windows programs off of non-global drives, and under Windows 
95, XCOPY starts the Windows console program XCOPY32.EXE. 

Implementation 


NTFSDOS scans the system's partition tables looking for partitions that 
have the NTFS attribute byte. When it finds one, it looks for an unused 
DOS driver letter and registers a network drive on it. After it 
completes the drive search it hooks the network redirector interrupt and 
goes resident. Requests come into NTFSDOS as full path names, or 
continuations of a previous directory traversal (as with findnext), so 
it proceeds to determine where, based on NTFS internal data structures, 
the target file is located. When it retrieves the header for the target 
file it can determine where the file's data is located, and read it when 
it receives requests to do so. 
To provide long filename support (LFN), NTFSDOS hooks INT 21/AH=0x71 
calls and implements LFN functionality when it sees an LFN call. Under 
Windows 95, NTFSHLP.VXD is required to send LFN calls down to the 
NTFSDOS for it to process; otherwise NTFSDOS would not see LFN calls 
since Windows assumes DOS redirected drives do not provide LFN support. 
The only API NTFSDOS uses is the INT 2F/11 API and INT 13. Otherwise the 
magic is just memory and cache management plus interpretation of the 
NTFS disk structures. 

Write-Access NTFSDOS


If there is sufficient interest we will implement a write-access version 
of NTFSDOS. The expected cost of the version will be $35. If you would 
like to purchase a copy if and when it becomes available, please notify 
us (see Reaching Us, below) by e-mail and be sure to let us know how 
many copies you would want. 

Reaching Us 


We would appreciate any feedback you have concerning this utility 
including suggestions and bug reports. Mark can be reached at 
markr@numega.com, and Bryce can be reached at cogswell@cs.uoregon.edu. 
NOTE: this product is in no way connected with, or endorsed by, Nu-Mega 
Technologies or the University of Oregon. 

Acknowledgments 


We thank everybody that e-mailed us with bug reports and other feedback. 

Significant understanding of the NTFS file system layout was derived by 
studying the Linux-based NTFS driver code maintained by Martin von 
Loewis. We acknowledge his indirect contribution to this endeavor. 
The book  Undocumented DOS by Andrew Schulman et al. (2nd edition, 
Addison-Wesley), was invaluable in providing network redirector 
information necessary for implementing NTFSDOS. 
------------------------------------------------------------------------

Visit these O'Reilly online areas: 
Our homepage, with product information, feature articles, and more. 
WebSite Central, home of O'Reilly's hot, new, Windows Web server. 
The O'Reilly Windows Center has Win 95 programming information, 
articles, and links.