Mount Processing

An FSR is tied up with the way Windows NT mounts volumes. Since the mount process defines how the FSR must operate, it is worth reviewing how mounting works on Windows NT.

A volume on Windows NT is mounted when it is accessed. Some volumes (such as the fixed disks on the system) are accessed during system initialization. Newly created volumes created with Disk Administrator or removable media volumes would be examples of disk volumes that are mounted much later. Thus, when you create a new disk partition and assign it a new drive letter, until an application program accesses that volume, it won’t actually be mounted. Similarly, when you change a floppy, the new floppy is not mounted until an application accesses it.

A Win32 application accesses the volume by using the drive letter typically. Of course, by now everyone knows these are actually symbolic links in the Object Manager name space—you can view these using the winobj utility in the SDK. Drive letters for physical volumes point to the device object for the physical media, not the file system.

When the I/O Manager finds a device object for a physical media device (that is, a device with the type FILE_DEVICE_DISK, FILE_DEVICE_TAPE, FILE_DEVICE_CD_ROM, or FILE_DEVICE_VIRTUAL_DISK) that device object will have a Volume Parameter Block (VPB) which will indicate if the volume has been mounted. If it has been mounted, the VPB will point to the device object belonging to the file system. If it has not been mounted, the I/O Manager will attempt to mount it.

Mounting consists of the I/O Manager calling each registered file system of the correct type (FILE_DEVICE_DISK_FILE_SYSTEM, FILE_DEVICE_TAPE_FILE_SYSTEM, or FILE_DEVICE_CD_ROM_FILE_SYSTEM) for the media volume. This is done by calling the file system’s IRP_MJ_FILE_SYSTEM_CONTROL dispatch entry point with the minor function code IRP_MN_MOUNT_VOLUME. The I/O Manager asks each file system in turn if the volume can be mounted by that particular file system. File systems are called in last registered, first called order, so the most recently loaded file system is the first one provided an opportunity to mount a volume.

The very first file system registered on Windows NT is the RAW file system—which actually registers three separate file system device objects—one for each type of media it might handle. Whenever the RAW file system is asked to mount a volume, it always does so. Volumes belonging to RAW can only be opened for "whole volume" access, and this is typically done by utilities such as Disk Administrator.

An FSR masquerades as a regular file system for the sole purpose of handling mount requests. Thus, it creates a device object of the appropriate file system type, registers it as a file system with the I/O Manager, and then waits to be called to mount volumes. When an FSR does recognize a volume as belonging to its file system, rather than accepting the mount request it returns the special error code STATUS_FS_DRIVER_REQUIRED. The I/O Manager then calls the FSR asking it to load the full file system driver. This is done by calling the IRP_MJ_FILE_SYSTEM_CONTROL dispatch entry point of the FSR with a minor function code of IRP_MN_LOAD_FILE_SYSTEM.

The principal advantage of using an FSR rather than simply loading the complete file system is that it saves memory—but only when the full FSD is not loaded. For customers who will only use the FSD on an infrequent basis, saving that additional memory can ensure that the performance of their system is not impacted when the FSD itself is not in use. Of course, even an FSR consumes some memory, but it will still be much smaller than the memory consumed by a complete FSD.