Background
When a program opens an exclusive file handle, the program assumes that the contents of the file cannot be modified any more. However, the contents of the file can be modified if the following conditions are true:
- Another program opens the file handle to the underlying volume or to the underlying disk.
- The program makes changes to the location where the file resides.
Corruption or system instability can occur when a program writes directly to a volume that is mounted by a file system without first obtaining exclusive access to the volume. This is because the write to the volume may collide with the file system writes. When such collisions occur, the contents of the volume may be left in an inconsistent state.
To reduce the effect of this issue, changes were made to the file system and to the storage stack to restrict direct access to the disk or to a volume.
Details of the change to the file system and to the storage stack
- A file system can write to a volume handle only if the following conditions are true:
- Condition 1: The sectors that are being written to are boot sectors.
Note This condition exists to support programs such as antivirus programs, Setup programs, and other programs that have to update the startup code of the system volume. The system volume cannot be locked. - Condition 2: The sectors that are being written to reside outside the file system space.
Note The region between the end of the file system space and the end of the volume space is not under the control of the file system. Therefore, there is no reason to require the volume to be locked to write to it. - Condition 3: The volume has been locked implicitly by requesting exclusive write access.
- Condition 4: The volume has been locked explicitly by requesting a lock request or an unmount request.
- Condition 5: The write request has a SL_FORCE_DIRECT_WRITE flag that indicates that Condition 2 must be bypassed.
Note There are file system filters that write to the free space region of a volume without first locking the volume. If the file system filters have to do this, the file system filters can set a flag on the write request that informs the file system to let the write occur. This flag can only be set from inside the kernel mode.
- The changes to the file system and to the storage stack do not apply if the volume is not mounted or if the volume has no file system.
- The UDFS file system and the FASTFAT file system limit the changes that are made to the file system and to the storage stack. These changes are limited to the disk type media.
Note Most CD-mastering programs write directly to the volume without first locking the volume. Some CD-mastering programs even bypass the file system layer. In these cases, such programs write directly to the storage layer. Because the paging file can only be hosted on disk drives, there is no reason to apply the changes that were made to the file system and to the storage stack to optical drives. - The storage drivers can write to a disk handle if the following conditions are true:
- Condition 1: The sectors that are being written to do not fall within a volume.
Note Programs use the sectors that are outside the volumes to store metadata. The partition tables also reside in the sectors that are outside the volumes. Because these sectors are not under the control of any file system, there is no reason to block access to the sectors. - Condition 2: The sectors that are being written to fall within a mounted volume that is locked explicitly.
- Condition 3: The sectors that are being written to fall within a volume that is not mounted or fall within a volume has no file system.
- The changes to the file system and to the storage stack will also apply to the parity blocks of a volume.
- The changes to the file system and to the storage stack will apply to 32-bit systems and to 64-bit systems.
In addition to the various WriteFile APIs, there are device IO control requests that may be used to issue writes to a volume or to a disk. The changes to the file system and to the storage stack will also apply to the device IO control requests. The device IO control requests include the following commands:
- IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES
-
IOCTL_SCSI_PASS_THROUGH
-
IOCTL_SCSI_PASS_THROUGH_DIRECT
-
SCSIOP_WRITE6
-
SCSIOP_WRITE
-
SCSIOP_WRITE_VERIFY
-
SCSIOP_WRITE_SAME
-
SCSIOP_WRITE_LONG
-
SCSIOP_XDWRITE
-
SCSIOP_XPWRITE
-
SCSIOP_XDWRITE_READ
-
SCSIOP_WRITE12
-
SCSIOP_WRITE_VERIFY12
-
SCSIOP_WRITE16
-
SCSIOP_WRITE_VERIFY16
-
SCSIOP_WRITE_SAME16
-
SCSIOP_WRITE_LONG16
-
SCSIOP_WRITE_XDWRITE_EXTENDED16
-
SCSIOP_WRITE_COPY
-
SCSIOP_WRITE_COPY_COMPARE
The following group of commands fails because they are obsolete:
- IOCTL_ATA_PASS_THROUGH
-
IOCTL_ATA_PASS_THROUGH_DIRECT
-
IDE_COMMAND_WRITE
-
IDE_COMMAND_WRITE_DMA
-
IDE_COMMAND_WRITE_DMA_QUEUED
-
IDE_COMMAND_WRITE_MULTIPLE
-
IDE_COMMAND_WRITE_EXT
-
IDE_COMMAND_WRITE_DMA_EXT
-
IDE_COMMAND_WRITE_DMA_FUA_EXT
-
IDE_COMMAND_WRITE_DMA_QUEUED_EXT
-
IDE_COMMAND_WRITE_DMA_QUEUED_FUA_EXT
-
IDE_COMMAND_WRITE_MULTIPLE_EXT
-
IDE_COMMAND_WRITE_MULTIPLE_FUA_EXT
For the SCSI commands, the 32-byte write commands are not filtered because there are only 16 bytes in the CDB. The extended xdwrite, the copy and the copy compare commands are failed.
For the ATA commands, the LBA bit is queried to determine whether the offset was specified in CHS format or in LBA format. Because the system cannot obtain the real geometry, all requests that are sent in CHS format are failed. This should not be a problem because all modern disks expect that the offset is in LBA format.
Program compatibility concerns and mitigations
The changes to the file system and to the storage stack may cause some programs to fail. Such programs fail because they use direct access to the disk or to the volume.
The effect on program compatibility will be minimal for the following reasons:
- Backup programs must unmount the volume before they write to the volume. Otherwise, the program writes will collide with file system writes. Such collisions will result in corruption or in system instability.
- Partitioning programs target partition tables that reside in sectors that are outside the volume regions. File systems do not control such sectors. Because access to these sectors is enabled, the partitioning programs are not affected.
- Recovery programs will most likely run on volumes that the file system cannot mount. Because access to RAW volumes is enabled, such recovery programs are not affected.
- Block level encryption programs usually have a filter driver that resides in the disk stack that is underneath the partition manager driver. The filter driver filters Input Output (IO) that the partition manager driver issues. Therefore, the changes to the file system and to the storage stack do not affect the block level encryption programs. If the filter driver resides in the volume stack, the filter driver will be underneath the file systems. Therefore, the changes to the file system and to the storage stack do not affect the block level encryption programs.
- CD-mastering programs are not affected because the UDFS file system and the FAT32 file system does not perform checks when the file system is mounted on optical drives.
However, CD-mastering programs can be affected in the following scenario:
- A program locks its file.
- The program queries the extents of the file.
- The program uses a volume handle to write directly to the extents of the file.
However, we do not encourage this scenario because this scenario can cause the file metadata to be out of sync. When file metadata is out of sync, file corruption can occur.