Minifilter drivers call FltCreateFileEx2 to create a new file or open an existing file. This routine also includes an optional create context parameter.
NTSTATUS FltCreateFileEx2( _In_ PFLT_FILTER Filter, _In_opt_ PFLT_INSTANCE Instance, _Out_ PHANDLE FileHandle, _Out_ PFILE_OBJECT *FileObject, _In_ ACCESS_MASK DesiredAccess, _In_ POBJECT_ATTRIBUTES ObjectAttributes, _Out_ PIO_STATUS_BLOCK IoStatusBlock, _In_opt_ PLARGE_INTEGER AllocationSize, _In_ ULONG FileAttributes, _In_ ULONG ShareAccess, _In_ ULONG CreateDisposition, _In_ ULONG CreateOptions, _In_opt_ PVOID EaBuffer, _In_ ULONG EaLength, _In_ ULONG Flags, _In_opt_ PIO_DRIVER_CREATE_CONTEXT DriverContext );
- Filter [in]
An opaque filter pointer for the caller.
- Instance [in, optional]
An opaque instance pointer for the minifilter driver instance that the create request is to be sent to. The instance must be attached to the volume where the file or directory resides. This parameter is optional and can be NULL. If this parameter is NULL, the request is sent to the device object at the top of the file system driver stack for the volume. If this parameter is non-NULL, the request is sent only to minifilter driver instances that are attached below the specified instance.
- FileHandle [out]
A pointer to a caller-allocated variable that receives the file handle if the call to FltCreateFileEx2 is successful.
- FileObject [out]
A pointer to a caller-allocated variable that receives the file object pointer if the call to FltCreateFileEx2 is successful. This parameter is optional and can be NULL.
- DesiredAccess [in]
A bitmask of flags that specify the type of access that the caller requires to the file or directory. The set of system-defined DesiredAccess flags determines the following specific access rights for file objects.
Note Do not specify FILE_READ_DATA, FILE_WRITE_DATA, FILE_EXECUTE, or FILE_APPEND_DATA when creating or opening a directory.
DesiredAccess flags Meaning
The file can be deleted.
Data can be read from the file.
FileAttributes flags can be read. For additional information, see the table of valid flag values in the FileAttributes parameter description below.
Extended attributes that are associated with the file can be read.
The access control list (ACL) and ownership information that is associated with the file can be read.
Data can be written to the file.
FileAttributes flags can be written.
Extended attributes that are associated with the file can be written.
Data can be appended to the file.
The discretionary access control list (DACL) that is associated with the file can be written.
Ownership information that is associated with the file can be written.
The caller can synchronize the completion of an I/O operation by waiting for the returned FileHandle to be set to the Signaled state. This flag must be set if the CreateOptions FILE_SYNCHRONOUS_IO_ALERT or FILE_SYNCHRONOUS_IO_NONALERT flag is set.
Use system paging I/O to read data from the file into system memory.
Alternatively, for any file object that does not represent a directory, you can specify one or more of the following generic ACCESS_MASK flags. The following table illustrates that a flag value in the left column is equivalent to the set of flag values in the right column. (The STANDARD_RIGHTS_XXX flags are predefined system values that are used to enforce security on system objects.) You can also combine these generic flags with additional flags from the preceding table.
DesiredAccess values Maps to DesiredAccess flags
STANDARD_RIGHTS_READ, FILE_READ_DATA, FILE_READ_ATTRIBUTES, FILE_READ_EA, and SYNCHRONIZE
STANDARD_RIGHTS_WRITE, FILE_WRITE_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, FILE_APPEND_DATA, and SYNCHRONIZE
STANDARD_RIGHTS_EXECUTE, SYNCHRONIZE, FILE_READ_ATTRIBUTES, and FILE_EXECUTE
For directories, you can specify one or more of the following ACCESS_MASK flags, which you can also combine with any compatible flags that were described in the preceding tables.
DesiredAccess flags - for directories Meaning
Files in the directory can be listed.
The directory can be traversed: that is, it can be part of the pathname of a file.
- ObjectAttributes [in]
A pointer to an opaque OBJECT_ATTRIBUTES structure that is already initialized with InitializeObjectAttributes. If the caller is running in the system process context, this parameter can be NULL. Otherwise, the caller must set the OBJ_KERNEL_HANDLE attribute in the call to InitializeObjectAttributes. Members of this structure for a file object are listed in the following table.
The number of bytes of data that are contained in the structure pointed to by ObjectAttributes. This value must be at least sizeof(OBJECT_ATTRIBUTES).
A pointer to a UNICODE_STRING structure that contains the name of the file to be created or opened. This name must be a fully qualified file specification or the name of a device object unless it is the name of a file relative to the directory specified by RootDirectory. For example, "\Device\Floppy1\myfile.dat" or "\??\B:\myfile.dat" could both be valid file specifications, if the floppy driver and overlying file system are already loaded. (Note: "\??" replaces "\DosDevices" as the name of the Win32 object namespace. "\DosDevices" still works, but "\??" is translated faster by the object manager.)
An optional handle to a directory, obtained by a preceding call to FltCreateFileEx2. If this value is NULL, the ObjectNamemember must be a fully qualified file specification that includes the full path to the target file. If this value is non-NULL, the ObjectName member specifies a file name that is relative to this directory.
An optional security descriptor (SECURITY_DESCRIPTOR) to be applied to a file. ACLs specified by such a security descriptor are only applied to the file when it is created. If the value is NULL when a file is created, the ACL placed on the file is file-system-dependent. Most file systems propagate some part of such an ACL from the parent directory file combined with the caller's default ACL.
A set of flags that controls the file object attributes. If the caller is running in the system process context, this parameter can be zero. Otherwise, the caller must set the OBJ_KERNEL_HANDLE flag. The caller can also optionally set the OBJ_CASE_INSENSITIVE flag, which indicates that name-lookup code should ignore the case of ObjectName rather than performing an exact-match search.
- IoStatusBlock [out]
A pointer to an IO_STATUS_BLOCK structure that receives the final completion status and information about the requested operation. On return from FltCreateFileEx2, the Information member of the variable contains one of the following values.
- AllocationSize [in, optional]
Optionally specifies the initial allocation size, in bytes, for the file stream. A nonzero value has no effect unless the file is being created, overwritten, or superseded.
- FileAttributes [in]
Specifies one or more of the following FILE_ATTRIBUTE_XXX flags, which represent the file attributes to set if you are creating, superseding, or overwriting a file. Normally, you specify FILE_ATTRIBUTE_NORMAL, which sets the default attributes.
FileAttributes flags Meaning
A file with standard attributes should be created.
A read-only file should be created.
A hidden file should be created.
A system file should be created.
An archive file should be created. This attribute is used to mark files for backup or removal.
A temporary file should be created.
- ShareAccess [in]
Specifies the type of share access to the file that the caller requires, as zero or one, or a combination of the following flags. If the IO_IGNORE_SHARE_ACCESS_CHECK flag is specified in the Flags parameter, the I/O manager ignores this parameter. However, the file system might still perform access checks. Thus, it is important to specify the sharing mode you would like for this parameter, even when using the IO_IGNORE_SHARE_ACCESS_CHECK flag. For the greatest chance of avoiding sharing violation errors, specify all of the following share access flags.
ShareAccess flags Meaning
The file can be opened for read access by other threads' calls to FltCreateFileEx2.
The file can be opened for write access by other threads' calls to FltCreateFileEx2.
The file can be opened for delete access by other threads' calls to FltCreateFileEx2.
- CreateDisposition [in]
Specifies a value that determines the action to be taken, depending on whether the file already exists. The value can be any of those described in the following table.
CreateDisposition values Meaning
If the file already exists, replace it with the given file. If it does not, create the given file.
If the file already exists, fail the request and do not create or open the given file. If it does not, create the given file.
If the file already exists, open it instead of creating a new file. If it does not, fail the request and do not create a new file.
If the file already exists, open it. If it does not, create the given file.
If the file already exists, open it and overwrite it. If it does not, fail the request.
If the file already exists, open it and overwrite it. If it does not, create the given file.
- CreateOptions [in]
Specifies the options to be applied when creating or opening the file, as a compatible combination of the following flags.
CreateOptions flags Meaning
The file that is being created or opened is a directory file. With this flag, the CreateDisposition parameter must be set to one of FILE_CREATE, FILE_OPEN, or FILE_OPEN_IF. With this flag, other compatible CreateOptions flags include only the following: FILE_SYNCHRONOUS_IO_ALERT, FILE_SYNCHRONOUS_IO_NONALERT, FILE_WRITE_THROUGH, FILE_OPEN_FOR_BACKUP_INTENT, and FILE_OPEN_BY_FILE_ID.
The file that is being opened must not be a directory file or this call fails. The file object that is being opened can represent a data file; a logical, virtual, or physical device; or a volume.
System services, file systems, and drivers that write data to the file must actually transfer the data into the file before any requested write operation is considered complete. This flag is automatically set if the CreateOptions flag FILE_NO_INTERMEDIATE_BUFFERING is set.
All accesses to the file will be sequential.
Accesses to the file can be random, so no sequential read-ahead operations should be performed on the file by file systems or the operating system.
The file cannot be cached or buffered in a driver's internal buffers. This flag is incompatible with the DesiredAccessFILE_APPEND_DATA flag.
All operations on the file are performed synchronously. Any wait on behalf of the caller is subject to premature termination from alerts. This flag also causes the I/O system to maintain the file position context. If this flag is set, the DesiredAccess SYNCHRONIZE flag also must be set so that the I/O Manager uses the file object as a synchronization object.
All operations on the file are performed synchronously. Waits in the system to synchronize I/O queuing and completion are not subject to alerts. This flag also causes the I/O system to maintain the file position context. If this flag is set, the DesiredAccess SYNCHRONIZE flag also must be set so that the I/O Manager uses the file object as a synchronization object.
Create a tree connection for this file in order to open it over the network.
Complete this operation immediately with an alternate success code if the target file is oplocked, rather than blocking the caller's thread. If the file is oplocked, another caller already has access to the file over the network.
If the extended attributes on an existing file that is being opened indicate that the caller must understand extended attributes to properly interpret the file, fail this request because the caller does not understand how to deal with extended attributes.
Open a file with a reparse point and bypass normal reparse point processing for the file. For more information, see the following Remarks section.
Delete the file when the last handle to it is passed to FltClose.
The file is being opened by ID. The file name contains the name of a device and a 64-bit ID to be used to open the file.
The file is being opened for backup intent. Therefore, the system should check for certain access rights and grant the caller the appropriate accesses to the file before checking the input DesiredAccess against the file's security descriptor.
The file is being opened and an opportunistic lock (oplock) on the file is being requested as a single atomic operation. The file system checks for oplocks before it performs the create operation, and the create will fail with a return code of STATUS_CANNOT_BREAK_OPLOCK if the create would break an existing oplock.
Note The FILE_OPEN_REQUIRING_OPLOCK flag is available in Windows 7, Windows Server 2008 R2 and later Windows operating systems.
This flag allows an application to request a Filter opportunistic lock (oplock) to prevent other applications from getting share violations. If there are already open handles, the create request will fail with STATUS_OPLOCK_NOT_GRANTED. For more information, see the following Remarks section.
- EaBuffer [in, optional]
A pointer to a caller-supplied FILE_FULL_EA_INFORMATION buffer that contains extended attribute (EA) information to be applied to the file.
- EaLength [in]
Length, in bytes, of EaBuffer.
- Flags [in]
Specifies options to be used during the creation of the create request. The following table lists the available options.
Options flags Meaning
Indicates that the I/O manager must check the create request against the file's security descriptor.
Indicates that the I/O manager should not perform share-access checks on the file object after it is created. However, the file system might still perform these checks.
Indicates that the parameters for this call should not be validated before attempting to issue the create request. Driver writers should use this flag with caution because certain invalid parameters can cause a system failure.
- DriverContext [in, optional]
FltCreateFileEx2 returns STATUS_SUCCESS or an appropriate NTSTATUS value such as one of the following:
The filter or instance specified in the Filter or Instance parameters is being torn down. This status code can be received if the open request crosses a volume mount point and the Instance parameter is non-NULL. This is an error code.
FltCreateFileEx2 encountered a pool allocation failure. This is an error code.
The file or directory name contains a mount point that resolves to a volume other than the one that the specified minifilter driver instance is attached to. This is an error code.
The ObjectAttributes parameter did not contain a RootDirectory member, but the ObjectName member in the OBJECT_ATTRIBUTES structure was an empty string or did not contain an OBJECT_NAME_PATH_SEPARATOR character. This error code indicates incorrect syntax for the object path.
This value will be returned if the DriverContext parameter points to a valid IO_DRIVER_CREATE_CONTEXT structure and the DeviceObjectHint member of this structure is not NULL. This is an error code.
Note FltCreateFileEx2 might return STATUS_FILE_LOCK_CONFLICT as the return value or in the Status member of the IO_STATUS_BLOCK structure that is pointed to by the IoStatusBlock parameter. This would occur only if the NTFS log file is full, and an error occurs while FltCreateFileEx2 tries to handle this situation.
To specify an extra create parameter (ECP) as part of a create operation, initialize the ExtraCreateParameter member of the IO_DRIVER_CREATE_CONTEXT structure with the FltAllocateExtraCreateParameterList routine. If ECPs are used, they must be created, manipulated, and freed using the appropriate routines - the following See Also section lists these routines. Upon returning from the call of FltCreateFileEx2, the ECP list is unchanged and may be passed to additional calls of FltCreateFileEx2 for other create operations. Note that the operating system does not automatically deallocate the ECP list structure - the caller of FltCreateFileEx2 must deallocate this structure by calling the FltFreeExtraCreateParameterList routine.
To create/open a file in the context of a transaction, set the TxnParameters member of the IO_DRIVER_CREATE_CONTEXT structure to the value returned by the IoGetTransactionParameterBlock routine.
For additional information regarding transactions, see Transaction Management (TxF).
FltCreateFileEx2 sends the create request only to the instances attached below the specified minifilter driver instance and to the file system. The specified instance and the instances attached above it do not receive the create request. If no instance is specified, the request goes to the top of the stack and is received by all instances and the file system.
There are two alternate ways to specify the name of the file to be created or opened with FltCreateFileEx2:
As a fully qualified pathname, supplied in the ObjectName member of the input ObjectAttributes.
As a pathname that is relative to the directory file represented by the handle in the RootDirectory member of the input ObjectAttributes.
Any FileHandle that is obtained from FltCreateFileEx2 must eventually be released by calling FltClose. In addition, any returned FileObject pointer must be dereferenced when it is no longer needed by calling ObDereferenceObject.
Driver routines that do not run in the system process context must set the OBJ_KERNEL_HANDLE attribute for the ObjectAttributes parameter of FltCreateFileEx2. Setting this attribute restricts the use of the handle that is returned by FltCreateFileEx2 to processes running in kernel mode. Otherwise, the handle can be accessed by the process in whose context the driver is running.
Certain DesiredAccess flags and combinations of flags have the following effects:
For a caller to synchronize an I/O completion by waiting for the returned FileHandle to be set to the Signaled state, the SYNCHRONIZE flag must be set.
If only the FILE_APPEND_DATA and SYNCHRONIZE flags are set, the caller can write only to the end of the file, and any offset information about write requests to the file is ignored. However, the file is automatically extended as necessary for this type of write operation.
Setting the FILE_WRITE_DATA flag for a file also allows write requests beyond the end of the file to occur. The file is automatically extended for this type of write request, as well.
If only the FILE_EXECUTE and SYNCHRONIZE flags are set, the caller cannot use the handle returned in the FileHandle parameter to directly read or write any data to or from the file. That is, all operations on the file must use system paging I/O to read or write file data.
The ShareAccess parameter determines whether separate threads can access the same file, possibly simultaneously. If both file openers have the privilege to access a file in the specified manner, the file can be successfully opened and shared. If the original caller of FltCreateFileEx2 does not specify FILE_SHARE_READ, FILE_SHARE_WRITE, or FILE_SHARE_DELETE, no other open operations can be performed on the file because the original caller is given exclusive access to the file.
For a shared file to be successfully opened, the requested DesiredAccess to the file must be compatible with both the DesiredAccess and ShareAccess specifications of all preceding open requests that have not yet been released with FltClose. That is, the DesiredAccess parameter that is specified to FltCreateFileEx2 for a given file must not conflict with the accesses that other openers of the file have disallowed.
Note If IO_IGNORE_SHARE_ACCESS_CHECK is specified in the Flags parameter, the I/O manager ignores the ShareAccess parameter. However, the file system might still perform access checks. Thus, it is important to specify the sharing mode you would like for the ShareAccessparameter, even when using the IO_IGNORE_SHARE_ACCESS_CHECK flag.
The CreateDisposition value FILE_SUPERSEDE requires that the caller have DELETE access to an existing file object. If so, a successful call to FltCreateFileEx2 with FILE_SUPERSEDE on an existing file effectively deletes that file and then recreates it. This implies that if the file has already been opened by another thread, it opened the file by specifying a ShareAccessparameter with the FILE_SHARE_DELETE flag set. Note that this type of disposition is consistent with the POSIX style of overwriting files.
The CreateDisposition values FILE_OVERWRITE_IF and FILE_SUPERSEDE are similar. If FltCreateFileEx2 is called with an existing file and either of these CreateDisposition values, the file is replaced.
Overwriting a file is semantically equivalent to a supersede operation, except for the following:
The caller must have write access to the file, rather than delete access. This implies that, if the file has already been opened by another thread, it opened the file with the FILE_SHARE_WRITE flag set in the input ShareAccess parameter.
The specified file attributes are combined with those attributes that are already applied to the file by using a bitwise OR operation. This implies that if the file has already been opened by another thread, a subsequent caller of FltCreateFileEx2 cannot disable existing FileAttributes flags but can enable additional flags for the same file. Note that this style of overwriting files is consistent with MS-DOS, Windows 3.1, and OS/2.
The CreateOptions FILE_DIRECTORY_FILE value specifies that the file to be created or opened is a directory file. When a directory file is created, the file system creates an appropriate structure on the disk to represent an empty directory for that particular file system's on-disk structure. If this option was specified and the given file to be opened is not a directory file or if the caller specified an inconsistent CreateOptions or CreateDisposition value, the call to FltCreateFileEx2 fails.
The CreateOptions FILE_NO_INTERMEDIATE_BUFFERING flag prevents the file system from performing any intermediate buffering on behalf of the caller. Specifying this value places certain restrictions on the caller's parameters to other Flt..File routines or Zw..File routines, including the following:
The Length parameter passed to FltReadFile, ZwReadFile, FltWriteFile, or ZwWriteFile must be a multiple of the sector size. Note that specifying a read operation to a buffer whose length is exactly the sector size might result in fewer significant bytes being transferred to that buffer if the end of the file was reached during the transfer.
Buffers must be aligned in accordance with the alignment requirement of the underlying storage device. This information can be obtained by calling FltCreateFileEx2 to get a handle for the file object that represents the physical device and then calling ZwQueryInformationFile with that handle, specifying FileAlignmentInformation as the value for FileInformationClass parameter. For more information about the system FILE_XXX_ALIGNMENT values, which are defined in Ntifs.h, see DEVICE_OBJECT and Initializing a Device Object.
The CreateOptions FILE_SYNCHRONOUS_IO_ALERT and FILE_SYNCHRONOUS_IO_NONALERT flags, which are mutually exclusive as their names suggest, specify that the file is being opened for synchronous I/O. This means that all I/O operations on the file are to be synchronous as long as they occur through the file object that the returned FileHandle refers to. All I/O on such a file is serialized across all threads by using the returned handle. With either of these CreateOptions flags set, the I/O Manager maintains the current file position offset in the file object's CurrentByteOffset field. This offset can be used in calls to ZwReadFile and ZwWriteFile. It can also be queried or set by calling ZwQueryInformationFile or ZwSetInformationFile.
If the CreateOptions FILE_OPEN_REPARSE_POINT flag is not specified and FltCreateFileEx2 attempts to open a file with a reparse point, normal reparse point processing occurs for the file. If, on the other hand, the FILE_OPEN_REPARSE_POINT flag is specified, normal reparse processing does not occur and FltCreateFileEx2 attempts to directly open the reparse point file. In either case, if the open operation was successful, FltCreateFileEx2 returns STATUS_SUCCESS; otherwise, the routine returns an NTSTATUS error code. FltCreateFileEx2 never returns STATUS_REPARSE.
The CreateOptions FILE_OPEN_REQUIRING_OPLOCK flag eliminates the time between when you open the file and request an oplock that could potentially enable a third party to open the file and get a sharing violation. An application can use the FILE_OPEN_REQUIRING_OPLOCK flag on FltCreateFileEx2 and then request any oplock. This ensures that an oplock owner will be notified of any later open request that causes a sharing violation.
In Windows 7, if other handles exist on the file when an application uses the FILE_OPEN_REQUIRING_OPLOCK flag, the create operation will fail with STATUS_OPLOCK_NOT_GRANTED. This restriction no longer exists starting with Windows 8.
If this create operation would break an oplock that already exists on the file, then setting the FILE_OPEN_REQUIRING_OPLOCK flag will cause the create operation to fail with STATUS_CANNOT_BREAK_OPLOCK. The existing oplock will not be broken by this create operation.
An application that uses this flag must request an oplock after this call succeeds, or all later attempts to open the file will be blocked without the benefit of typical oplock processing. Similarly, if this call succeeds but the later oplock request fails, an application that uses this flag must close its handle after it detects that the oplock request has failed.
Note The FILE_OPEN_REQUIRING_OPLOCK flag is available in Windows 7, Windows Server 2008 R2 and later Windows operating systems. The Microsoft file systems that implement this flag in Windows 7 are NTFS, FAT, and exFAT.
The CreateOptions flag FILE_RESERVE_OPFILTER allows an application to request a level 1, batch, or filter oplock to prevent other applications from getting share violations. However, FILE_RESERVE_OPFILTER is only practically useful for filter oplocks. To use it, you must complete the following steps:
- Issue a create request with CreateOptions of FILE_RESERVE_OPFILTER, DesiredAccess of exactly FILE_READ_ATTRIBUTES, and ShareAccess of exactly FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE.
- If there are already open handles, the create request fails with STATUS_OPLOCK_NOT_GRANTED, and the next requested oplock also fails.
- If you open with more access or less sharing will also cause a failure of STATUS_OPLOCK_NOT_GRANTED.
If the create request succeeds, request an oplock.
Open another handle to the file to do I/O.
Step three makes this practical only for filter oplocks. The handle opened in step 3 can have a DesiredAccess that contains a maximum of FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES | FILE_READ_DATA | FILE_READ_EA | FILE_EXECUTE | SYNCHRONIZE | READ_CONTROL and still not break a filter oplock. However, any DesiredAccess greater than FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES | SYNCHRONIZE will break a level 1 or batch oplock and make the FILE_RESERVE_OPFILTER flag useless for those oplock types.
NTFS is the only Microsoft file system that implements FILE_RESERVE_OPFILTER.
Note If you try to open a volume but only specify a combination of the following flags for the DesiredAccess parameter, FltCreateFileEx2 will open a handle, independent of the file system, that has direct access to the storage device for the volume.
You must not use FltCreateFileEx2 to open a handle with direct access to the storage device for the volume or you will leak system resources. If you want to open a handle with direct access to a storage device, call the IoCreateFileEx, IoCreateFileSpecifyDeviceObjectHint, or ZwCreateFile function instead.
When a caller of FltCreateFileEx2 wishes to enable reparsing for a volume target, a FLT_CREATEFILE_TARGET_ECP_CONTEXT can be included as an ECP to the ECP list in the DriverContext parameter. If this ECP is present, FltCreateFileEx2 will adjust the target device for the create operation and attempt for find a filtered instance of a volume appropriate for the given file information. Use of this ECP is available starting with Windows 8.
|Available in starting with Windows Vista.|
Build date: 11/21/2012