Windows File System filter driver development tutorial (11)

11. Open, close, and delete file and directory generation

We have analyzed the read, and the write is similar to the read. There are other operations in the file system. For example, open a file or directory (open an existing directory or create a new one) and close it. Move or delete files or directories.

In fact, file_object is not just a file object. In Windows file systems, both directories and files are abstracted using fileobject. Here is a problem. For an existing fileobject, how can I determine whether it is a directory or a file?

For an existing fileobject, I have not found any better method except to send IRP to ask the volume device for the fileobject information. It is annoying to send IRP by yourself. It's not something I would like to do. However, fileobject was born during createfile. In the process of its birth, we did have the opportunity to get the new fileobject, whether it is a file or a directory.

When creating, obtain the current io_stack_location. Assume It is irpsp, then the structure of irpsp-> parameters. Create is:

Struct {
Pio_security_context securitycontext;
Ulong options;
Ushort fileattributes;
Ushort allow access;
Ulong ealength;
};

Parameters in this structure correspond to parameters in the createfile API. Please study them yourself. I will first write some function packages to facilitate reading irpsp.

_ Inline wd_ulong wd_irpsp_file_opts (wd_irpsp * irpsp)
{
Return irpsp-> parameters. Create. options;
}

_ Inline wd_ushort wd_irpsp_file_attrs (wd_irpsp * irpsp)
{
Return irpsp-> parameters. Create. fileattributes;
}

Enum {wd_file_opt_dir = file_directory_file };
Enum {wd_file_attr_dir = file_attribute_directory };

Then we can find out the meaning of options and fileattributes above. Is there a file_directory_file mark in options to indicate that this is a directory? In fact, createopen is a tentative action. In any case, it is only meaningful to judge fileobject when createopen is successful. Otherwise, it is empty talk.

There are two possibilities for success: Opening the original file or directory, and creating a new file or directory. In options, file_directory_file indicates that the opened or generated object is a directory. If it is confirmed that the file is successfully generated or opened in the create function, the returned file_object is indeed a directory.

When I often use the files or directory objects that I obtain when filtering, I usually capture them when the create operation is successful and record them in a "set. In this case, you have to write a Data Structure to show the "set. You can use a linked list or array to ensure the security of multiple threads. Because you have obtained the attribute to indicate whether the fileobject is a directory during create, you do not need to send IRP to ask about the fileobject attribute.

By the way, fileattributes exists above. But this is not reliable. Because you only need to set options when generating or opening. In my opinion, this field does not indicate that the object you opened is a directory.

You need to set the create function. If the settings are not repeated here, refer to the above operations on file reading.

Wd_stat my_create_comp (in wd_dev * Dev,
In wd_irp * IRP,
In wd_void * context)
{
Wd_irpsp * irpsp = wd_irp_cur_sp (IRP );
Wd_file * file = wd_irpsp_file (irpsp );

Unreferenced_parameter (Dev );

If (wd_suc (wd_irp_status (IRP ))
{
// If it succeeds, record the fileobject to the set. This is
// The directory you just opened or generated
If (file &&
(Wd_irpsp_file_opts (irpsp) & wd_file_opt_dir ))
Add_obj_to_set (File );
}
Return wd_irp_status (IRP );
}

Here, by the way, we will explain the unreferenced_parameter macro. I once did not understand the meaning of this macro. In fact, it is because this function has passed in three parameters that you may not use. If you don't need it, you know that the C compiler will issue a warning. It is generally believed that the driver should remove all warnings, so this macro is used to "use" unused parameters. You don't need them.

Now all directories are recorded by you. When you get a fileobject, you can determine that this fileobject is not in your collection. If it is in, it indicates that it is a directory, and if it is a file.

When this fileobject is closed, you should delete it from your collection. You can capture the close IRP to do this. I remember that this tutorial has installed the my_close function a long time ago to process IRP (please recall or read the content in section 3rd, delete the fileobject from your collection in this function. As an insurance measure, you should check whether the closure is successful. If it succeeds, you can delete the elements from the collection.

To determine whether a fileobject is a file or a directory, we have seen how to open or close a file. Now let's take a look at how files are deleted.

The first step is to open the file. When opening the file, you must set it to delete. If the file fails to be opened, the file cannot be deleted. Step 2: Set the file attribute to delete, and Step 3: close the file. When it is disabled, the file is deleted by the system.

However, please note that the "delete" here does not delete the file to the recycle bin. To test the file, you must press shift to delete the file permanently. Deleting a file to the recycle bin is only a renaming operation. The renaming operation will be discussed later.

The first step is to open the file. I should be able to capture the irpsp parameters when the file is opened. Remember the parameter structure of the front side, which includes:

Pio_security_context securitycontext;

The related structure is as follows:

Typedef struct _ io_security_context {
Psecurity_quality_of_service securityqos;
Paccess_state accessstate;
Access_mask desiredaccess;
Ulong fullcreateoptions;
} Io_security_context, * pio_security_context;

Note that desiredaccess must have the delete mark to delete the file.

The second step is to "delete when closing ". This is set by sending a set information. After capturing the IRP with the primary function code irp_mj_set_information:
First, irpsp-> parameters. setfile. fileinformationclass should be filedispositioninformation.

Then, IRP-> associatedirp. systembuffer points to the following structure:

Typedef struct _ file_disposition_information {
Boolean deletefile;
} File_disposition_information;

If deletefile is true, this operation deletes the file. The file will be deleted when the fileobject is closed.

I have not actually debugged all of the above, and I will not provide examplesCode. If you are interested, please complete it yourself.