Pagefile vs mappedfile & mm vs CC & irp_paging_io vs irp_nocache

/*
* Pagefile vs mappedfile & mm vs CC & irp_paging_io vs irp_nocache
* Sunwang <sunwangme@hotmail.com>
* 2005-10-20
*/

// Osr1
Irp_paging_io means that the IRP is paging I/O, for example if the IRP is irp_mj_write, then it is a paging write and since paging writes are not cached (are not wriites To File Cache), irp_paging_io implies irp_nocache_io, so to speak.
[If it is pageing, It is not cache. If it is not cache, is it paging? No! See osr3. but in this case = file_no_intermediate_buffering, and Io is performed in the unit of sector. for stream encrypt, you do not need to worry about RC4. However, if it is block encrypt, such as des, you still need to make a difference. file_no_intermediate_buffering is self-aligned.]

Irp_nocache_io, and not irp_paging_io so to speak, means that the IRP is not paging I/O, but it is not cached. for example if the IRP is irp_mj_write, then it is not a paging write, and it is non cached (is not a write to File Cache ). by way of example the user has opened the handle with createfile and file_flag_no_buffering.

There some important differences between these two cases. for example: in the case of paging I/O certain resources have been pre-acquired, whereas in the case of Non paging I/O these resources have not been pre-acquired; paging I/O cannot extend the end of file, whereas non paging I/O can extend the end of file.
[Paging tags are used by mm. If the user accesses invalid page to read files, such as mapped file/section, page fault will be generated, and mm will be responsible for transferring the tags to the memory; the write will be the same]

// Osr2
Irp_nocache means "do not use the data cache"
Irp_paging_io means "This I/O is on behalf of the VM System"

You will always see irp_nocache set if irp_paging_io is set in the irp_mj_read or irp_mj_write operation. You can see irp_nocache for a user level I/O operation that shoshould bypass the data cache.

For example, open a file and specify file_no_intermediate_buffering and the I/O operations will be irp_nocache.
[That is to say, the default file read/write is cache, so no mark is irp_cache, but it can be disabled through file_no_intermediate_buffering]

// Osr3
Irp_paging_io is always irp_nocache. The reverse is not true.

Irp_nocache without irp_paging_io is:
-Allowed to grow the file
-Delivered to the FSD without any FCB locks already held
This is the difference between it and irp_paging_io.

Such a request is delivered due to writefile to a noncached file.

// Osr4
Ifs FAQ:
Https://www.osronline.com/article.cfm? Id = 17

IRP-> flags (from installable File System kit)
======
There are several different possible IRP flags which control how underlying drivers (notably file systems) will interpret the contents of the I/O request itself.

Irp_nocache-data for this I/O Request shocould be read from the actual backing media and not from cache.

Irp_paging_io-the I/O operation in question is using Ming paging I/O. This bit is used by the Memory Manager.

Irp_mount_completion-the I/O operation in question is refreshing a mount operation.

Irp_synchronous_api-the API in question expects synchronous behavior. While synchronous behavior is advised when this bit is set, it is not required.

Irp_associated_irp-the IRP in question is associated with some larger I/O operation.

Irp_buffered_io-The associatedirp. systembuffer field is valid.

Irp_deallocate_buffer-The System Buffer was allocated from pool and shoshould be deallocated by the I/O manager.

Irp_input_operation-the I/O operation is for input. This is used by the Memory Manager to indicate a page in operation.

Irp_synchronous_paging_io-the paging operation shoshould complete synchronously. This bit is used by the Memory Manager.

Irp_create_operation-the IRP represents a file system create operation.

Irp_read_operation-the IRP represents a read operation.

Irp_write_operation-the IRP represents a write operation.

Irp_close_operation-the IRP represents a close operation.

Irp_defer_io_completion-the IRP shoshould be processed asynchronously. While asynchronous behavior is advised when this bit is set, it is not required.

Irp_mj_create: irpsp-> parameters. Create. Options (from installable File System kit)
======
Specifies the options to be applied when creating or opening the file. These options are specified as a compatible combination of the following flags.

File_directory_file-the file being created or opened is a directory file. if this flag is set, the disposition parameter must be set to one of file_create, file_open, or file_open_if. this flag is compatible with the following createoptions flags: file_synchronous_io_alert, file_synchronous_io_nonalert, file_write_through, file_open_for_backup_intent and file_open_by_file_id.

File_non_directory_file-the file being opened must not be a directory file or this call will fail. The file object being opened must represent a data file.

File_write_through-system services, fsds, and drivers that write data to the file must actually transfer the data into the file before any requested write operation is considered complete.

File_sequential_only-All accesses to the file will be sequential.

File_random_access-accesses to the file can be random, so no sequential read-ahead operations shoshould be stored med on the file by fsds or the system.

File_no_intermediate_buffering-the file cannot be cached or buffered in a driver's internal buffers. This flag is incompatible with the desiredaccess file_append_data flag.
[Callers of zwreadfile must have already called zwcreatefile with the desiredaccess flag reset set, either explicitly or by setting this flag using beyond the preceding call to zwcreatefile set the createoptions flag release, the length and byteoffset parameters to zwreadfile must be an integral of the sector size. for more information, see zwcreatefile.] [If this flag exists, read/write/filedispositioninformation is in the unit of sector]

File_synchronous_io_alert-all operations on the file are synchronized med 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.

File_synchronous_io_nonalert-all operations on the file are synchronized med synchronously. waits that exist 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.

File_create_tree_connection-create a tree connection for this file in order to open it over the network.

File_complete_if_oplocked-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.

Failed-if the extended attributes on an existing file being opened indicate that the caller must understand EAS to properly interpret the file, fail this request because the caller does not understand how to deal with EAS.

File_delete_on_close-delete the file when the last handle to it is passed to zwclose.

File_open_by_file_id-the file name specified in the objectattributes parameter des the 8-byte file reference number for the file. this number is assigned by the file system and is file-system-specific. if the file is a reparse point, the file name also has des the name of a device. note: The FAT file system does not support file_open_by_file_id.

File_open_for_backup_intent-the file is being opened for backup intent, hence, the system shoshould 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.

Irp_mj_create: irpsp-> parameters. Create. securitycontext-> desiredaccess (from installable File System kit)
======
Bitmask of flags specifying 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. desiredaccess flags meaning

Delete-the file can be deleted.

File_read_data-data can be read from the file.

File_read_attributes-fileattributes flags, described later, can be read.

File_read_ea-extended attributes (EA) associated with the file can be read.

Read_control-the access control list (ACL) and ownership information associated with the file can be read.

File_write_data-data can be written to the file.

File_write_attributes-fileattributes flags can be written.

File_write_ea-extended attributes associated with the file can be written.

File_append_data-data can be appended to the file.

Write_dac-the Discretionary Access Control List (DACL) associated with the file can be written.

Write_owner-ownership information associated with the file can be written.

Synchronize-the caller can wait on the returned filehandle to synchronize with the completion of an I/O operation. This flag must be set if the createoptions file_synchronous_io_alert or specified flag is set.

File_execute-data can be read into memory from the file using system paging I/O.

Irp_mj_create: IRP-> iostatus (from installable File System kit)
======
Pointer to an io_status_block structure that matches es the final completion status and information about the requested operation. The file system sets the Information Member of this structure to one of the following values:

File_created [use this mark to determine if a new file has been created]

File_does_not_exist

File_exists

File_opened

File_overwritten

File_superseded

NT: filedispositioninformation (from installable File System kit) [you can disable file deletion here]
NT: filerenameinformation [rename prohibited here]
NT: fileendoffileinformation [this will also affect Data]
======
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 following. Disposition values meaning

File_supersede-if the file already exists, replace it with the given file. If it does not, create the given file.

File_create-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.

File_open-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.

File_open_if-if the file already exists, open it. If it does not, create the given file.

File_overwrite if-the file already exists, open it and overwrite it. If it does not, fail the request.

File_overwrite_if-if the file already exists, open it and overwrite it. If it does not, create the given file.