BUG 2

home *** CD-ROM | disk | FTP | other *** search

/ BUG 2 / BUGCD1997_01.iso / utils / ntfsdos / ntfsdriv.exe / README.TXT < prev

Wrap

Text File | 1996-11-04 | 13.3 KB | 327 lines

====================================================================== NTFS File System Driver for DOS/Windows V1.21 (read-only) Copyright (C) 1996 Mark Russinovich and Bryce Cogswell Last modified November 2, 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 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. Availability ============ The latest version of NTFSDOS can be found at http://www.ntinternals.com Sample Output ============= 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.21 (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:\> ---------------------------------------------------------------------- Enhancements over V1.1 ====================== NTFSDOS V1.21 has the following improvements over V1.1: - Support for NT 4.0 formatted drives - Command line options for cache sizing and drive mapping - Support for large drives (>2GB). If extended INT13 services are present in the BIOS, NTFSDOS will use them to access drives. - Conflicts with MSCDEX fixed. NTFSDOS can now co-exist with Microsoft's real-mode CD-ROM driver. - Drive detection fixed. NTFSDOS no longer confuses HPFS drives for NTFS (finally!). - Several minor bug fixes. Enhancement over V1.2 ===================== Some BIOS falsely report support for extended interrupt 13 disk services, which caused NTFSDOS V1.2 some grief. NTFSDOS V1.21 has been made tolerant of these BIOS, and as an additional measure a new command-line switch has been added that can force NTFSDOS to use standard int 13 services to access disks. Contents of 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 Installation and Use ==================== To use NTFSDOS, simply execute it from the DOS command line (DOS 5.0 or greater is required), or from your AUTOEXEC.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. NTFSDOS takes five command line parameters. The /D parameter lets you specify which driver letter NTFSDOS should start at when it determines where to mount an NTFS drive. The /C option lets you override the default XMS cache size. The /N parameter disables NTFSDOS support for compressed files, and should be used to minimize memory usage when the drives you access do not contain compressed files. The /X switch forces NTFSDOS to use standard int 13 services, ignoring extended int 13 services if they are present. This should be used if NTFSDOS has trouble accessing your disk with extended int 13. Finally, the /V option directs NTFSDOS to print some messages detailing the drives it looks at the memory it allocates. The syntax for these parameters is: /D:<letter> Specifies drive to start mounting at /C:<size> Specifies size of XMS cache in KB /V Verbose Example: NTFSDOS /D:e /C:1024 This command has NTFSDOS start scanning for available drive letters at drive letter 'e' and indicates that it should create a 1MB XMS cache. There is no way to unload NTFSDOS from memory once it has started. If You Have Problems Running NTFSDOS ==================================== * NTFSDOS does not recognize my NTFS drive NTFSDOS does not handle cluster sizes > 4K on NT 4.0 formatted drives. This is rare, since NTFS compression does not handle these cluster sizes either. NTFSDOS requires that disks be accessible via BIOS, using the INT 13 or extended INT 13 services. In some cases, SCSI drives may not be fully accessible without a DOS device driver (see your SCSI adapter documentation). * NTFSDOS uses too much conventional memory Some people have complained that NTFSDOS is a memory hog. Unfortunately, this fact is largely imposed on us by the architecture of NTFS itself (sorry, but its a *little* more complicated than FAT, and much more memory intensive), coupled with our desire to provide reasonable performance across a wide variety of NTFS installations. In general, the footprint of NTFSDOS increases largely with the clustersize of the largest NTFS partition, and slightly with the number of NTFS volumes mounted. * 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, UNLESS the computer's BIOS has extended INT 13 support for the drives in question. The latter restrictions are due to limitations in standard 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. Reporting Bugs ============== When you report a bug (see Reaching Us, below), please provide the following information about your system: - disk types (IDE, etc.) - disk and partition sizes - BIOS version - drive sizes and formats - version of NT that was used to format NTFS drives - version of NTFSDOS you are using - an output dump of NTFSDOS run with the /V (verbose) option. - version of DOS and/or Windows you are running NTFSDOS on 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. NTFSDOS also uses the INT 2F/11 and INT 13 APIs. Otherwise the magic is just memory and cache management plus interpretation of the NTFS on-disk structures. Reaching Us =========== We would appreciate any feedback you have concerning this utility including suggestions and bug reports. Mark can be reached at mark@osr.com, and Bryce can be reached at cogswell@cs.uoregon.edu. 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. Andrew Schulman, et. al.'s, book, Undocumented DOS 2nd Edition (Addison-Wesley), was invaluable in providing network redirector information necessary for implementing NTFSDOS.