Method for mounting backup mirror image into Windows volume

Abstract

The invention discloses a method for mounting a backup mirror image into a Windows volume. The method comprises the following steps: S1, initializing a driving program; the method comprises the following steps: firstly, creating a temporary directory F in a Windows NT object manager namespace, creating a plurality of pieces of equipment of which the types are disks under the temporary directory F, and initializing an event object E in DEVICEXTENSION after the creation is successful, S2, calling PsCreate System Thread to create a working thread for the disk equipment, and S3, assigning a response column and a drive unloading routine of an IRP for a drive program. And S4, waiting for the working thread to be triggered by the event object E. According to the method, the temporary directory and the disk equipment are created in the Windows NT object manager, and the backup mirror image is mounted in the operating system as a new volume, so that data in the mirror image file can be accessed in a file form. By using the event object E, effective communication between the driving program and the working thread can be realized.

Description

Technical Field

[0001] The invention belongs to the technical field of data backup, and in particular is a method for mounting a backup image as a Windows volume. Background Art

[0002] With the continuous development and improvement of Windows operating system, more and more enterprises choose it as the operating system of their work computers. At the same time, the widespread application of computer virtualization has led to the large-scale use of various virtualization platforms in work. The traditional physical machine production method is limited by the physical environment or hardware aging, and faces the situation that the production equipment must be shut down when a failure occurs or replication is required. This not only brings inconvenience, but may also seriously affect normal work and production.

[0003] In the prior art, for example, the technical solution described in the patent with publication number CN115098299A is: a disaster recovery backup method for a virtual machine, including the steps of determining a backup request, creating a snapshot of a virtual disk image file of the virtual machine, determining the backup data of the virtual machine, etc., which can realize full backup and incremental backup of the virtual machine, thereby improving the efficiency and reliability of the disaster recovery backup of the virtual machine.

[0004] Since most backup software on the market currently uses a backup method that compresses and encrypts the data to be backed up, if a user wants to browse the contents of an image file, they usually need to restore the image before they can see the data in the image. Even if only a small amount of data is needed, a restore operation is required, which is very complicated for users, and users may not have a spare disk for the restore operation. Therefore, a method is invented that can directly mount an image file of a disk, partition, or system backup as a virtual volume and support reading, so that users can easily view the data in the backup source volume, copy data from the image file, directly open the files in the image file, and run the programs in the image file. Summary of the invention

[0005] The purpose of the present invention is to provide a method for mounting a backup image as a Windows volume, so as to solve the problem that in the prior art proposed in the background technology, a user usually needs to restore the image once before browsing the contents in the image file, which leads to a long time required for data restoration and very complicated data viewing for the user.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention is:

[0007] A method for mounting a backup image as a Windows volume includes the following steps:

[0008] Step S1, the driver is initialized; first, a temporary directory F is created under the WindowsNT object manager namespace, and multiple disk devices are created under the temporary directory F. After the creation is successful, the event object E in DEVICE_EXTENSION is initialized. The event object E is used to notify the working thread that an event is triggered;

[0009] Step S2, calling PsCreateSystemThread to create a working thread for the disk device, the initial state of the working thread is to wait for the triggering of the event object E;

[0010] Step S3, specifying an IRP response sequence and a driver uninstallation routine for the driver;

[0011] Step S4, waiting for the working thread to be triggered by the event object E. When the working thread is triggered by the event object E, the working thread enters the working state and processes the event object E accordingly.

[0012] According to the above technical solution, in step S1, multiple disk-type devices are created under the temporary directory F as follows: a disk-type device is created through IoCreateDeviceSecure, and when calling IoCreateDeviceSecure, a security descriptor string D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)(A;;GA;;;AU)(A;;GA;;;IU) needs to be specified, and the created device is set to read-only state.

[0013] According to the above technical solution, after the device is successfully created, KeInitializeEvent is called to initialize the event object E; then a linked list object L is initialized by calling InitializeListHead, and the linked list object is used to store IRP requests.

[0014] According to the above technical solution, in step S4, when the working thread is triggered by the event object E to enter the working state, the processing includes the following steps:

[0015] Step S401, determine whether the event object E is an end event, if yes, then end directly; if not, proceed to the next step;

[0016] Step S402, determine whether the linked list is empty, if so, return to step S3, wait for event object E to trigger; if not, take out the IRP from the linked list;

[0017] Step S403, determine whether the IRP is a read operation, if yes, process the read logic, set the IRP completion status, and return to step S402, waiting for the next event object E to trigger; if no, proceed to the next step;

[0018] Step S404, determine whether the IRP is a write operation; if so, process the write logic, set the IRP completion status, and return to step S402 to wait for the next event object E to trigger; if not, proceed to the next step;

[0019] Step S405, determine whether the IRP is a control code instruction, if so, process the control code instruction logic; if not, return to set the error, set the IRP completion status, and return to step S402, waiting for the next event object E to trigger.

[0020] According to the above technical solution, in step S403, when processing a read operation, it is necessary to obtain the starting position and the total number of bytes to be read from the parameters of the IRP, and both the starting byte and the total bytes need to be converted into sectors, wherein the starting sector is equal to the starting byte divided by the number of bytes in each sector, and the total sectors are equal to the total number of bytes to be read divided by the number of bytes in each sector.

[0021] According to the above technical solution, in step S404, the write logic is specifically processed as follows: directly returning a write failure message in the IRP_MJ_WRITE routine.

[0022] According to the above technical solution, in step S405, the control code instruction logic is specifically as follows: first determine whether the received control code instruction IRP_MJ_DEVICE_CONTROL request is a request to open a file or a request to close a file. If it is a request to open a file, it is processed through the file opening logic; if it is a request to close a file, it is processed through the file closing logic.

[0023] According to the above technical solution, if the IRP_MJ_DEVICE_CONTROL request received from the upper layer is a request to open a file, the driver will first use the security attributes passed in by the R3 layer to simulate, simulate the access rights of the current thread of the driver as having access rights, and then open the file by calling ZwCreateFile. If the file is opened successfully, the file name and handle information will be stored in the extended attributes of the device object. Finally, the file size and the alignment of the underlying buffer of the file are obtained and stored in the extended structure of the file device information, and then a notification of successful opening is returned.

[0024] According to the above technical solution, when opening a file, it is necessary to specify the file access permission as shared read, and obtain the file size and the alignment of the file's underlying buffer through ZwQueryInformationFile.

[0025] According to the above technical solution, if the IRP_MJ_DEVICE_CONTROL request received from the upper layer is an operation to close a file, the driver will close the H handle in the extended information of the device object, release the file-related resources, restore the related parameters to the initial values, and set the completion status of the IRP.

[0026] Compared with the prior art, the present invention has the following beneficial effects:

[0027] In the present invention, by creating a temporary directory and a disk device in the Windows NT object manager, the backup image is mounted as a new volume in the operating system, so that the data in the image file can be accessed in the form of a file. Using a working thread to process events, system resources are effectively utilized, while ensuring the responsiveness of the driver. Through the use of event object E, effective communication between the driver and the working thread can be achieved. The working thread can respond quickly after the event is triggered and start to execute the corresponding processing logic, thereby improving the reaction speed and efficiency of the system. During the initialization and processing process, there is a clear IRP response mechanism and uninstall routine, which can ensure that the driver can be safely uninstalled when an exception occurs, reducing the risk of system crashes. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 Mounting flow chart for the present invention;

[0029] Figure 2 This is a flow chart of volume response processing of the present invention. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] Embodiment 1

[0032] like Figure 1 As shown, a method for mounting a backup image as a Windows volume includes the following steps:

[0033] Step S1, the driver is initialized; first, a temporary directory F is created under the Windows NT object manager namespace, and multiple disk devices are created under the temporary directory F. After the creation is successful, the event object E in DEVICE_EXTENSION is initialized. The event object E is used to notify the working thread that an event is triggered;

[0034] Step S2, calling PsCreateSystemThread to create a working thread for the disk device, the initial state of the working thread is to wait for the triggering of the event object E;

[0035] Step S3, specifying an IRP response sequence and a driver uninstallation routine for the driver;

[0036] Step S4, waiting for the working thread to be triggered by the event object E. When the working thread is triggered by the event object E, the working thread enters the working state and processes the event object E accordingly.

[0037] In the present invention, by creating a temporary directory and a disk device in the Windows NT object manager, the backup image is mounted as a new volume in the operating system, so that the data in the image file can be accessed in the form of a file. Using a working thread to process events, the system resources are effectively utilized, and the responsiveness of the driver is guaranteed. Through the use of event object E, effective communication between the driver and the working thread can be achieved. The working thread can respond quickly after the event is triggered and start to execute the corresponding processing logic, thereby improving the reaction speed and efficiency of the system. During the initialization and processing process, there is a clear IRP response mechanism and uninstall routine, which can ensure that the driver can be safely uninstalled when an exception occurs, reducing the risk of system crashes.

[0038] Embodiment 2

[0039] This embodiment is a further refinement of the first embodiment.

[0040] In step S1, multiple disk-type devices are created under the temporary directory F as follows: disk-type devices are created through IoCreateDeviceSecure. When calling IoCreateDeviceSecure, the security descriptor string D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)(A;;GA;;;AU)(A;;GA;;;IU) needs to be specified, and the created device is set to read-only state.

[0041] After the device is successfully created, KeInitializeEvent is called to initialize the event object E; then a linked list object L is initialized by calling InitializeListHead. The linked list object is used to store IRP requests.

[0042] like Figure 2 As shown, in step S4, when the working thread is triggered by the event object E to enter the working state, the processing includes the following steps:

[0043] Step S401, determine whether the event object E is an end event, if yes, then end directly; if not, proceed to the next step;

[0044] Step S402, determine whether the linked list is empty, if so, return to step S3, wait for event object E to trigger; if not, take out the IRP from the linked list;

[0045] Step S403, determine whether the IRP is a read operation, if yes, process the read logic, set the IRP completion status, and return to step S402, waiting for the next event object E to trigger; if no, proceed to the next step;

[0046] Step S404, determine whether the IRP is a write operation; if so, process the write logic, set the IRP completion status, and return to step S402 to wait for the next event object E to trigger; if not, proceed to the next step;

[0047] Step S405, determine whether the IRP is a control code instruction, if so, process the control code instruction logic; if not, return to set the error, set the IRP completion status, and return to step S402, waiting for the next event object E to trigger.

[0048] In step S403, when processing a read operation, it is necessary to obtain the starting position and the total number of bytes to be read from the parameters of the IRP, and both the starting byte and the total bytes need to be converted into sectors, where the starting sector is equal to the starting byte divided by the number of bytes in each sector, and the total sectors are equal to the total number of bytes to be read divided by the number of bytes in each sector.

[0049] In step S404, the write logic is specifically processed as follows: a write failure message is directly returned in the IRP_MJ_WRITE routine.

[0050] In step S405, the control code instruction logic is specifically as follows: first determine whether the received control code instruction IRP_MJ_DEVICE_CONTROL request is a request to open a file or a request to close a file. If it is a request to open a file, it is processed through the file opening logic; if it is a request to close a file, it is processed through the file closing logic.

[0051] If the IRP_MJ_DEVICE_CONTROL request received from the upper layer is a request to open a file, the driver will first use the security attributes passed in by the R3 layer to simulate the access rights of the driver's current thread as having access rights, and then open the file by calling ZwCreateFile. If the file is opened successfully, the file name and handle information will be stored in the extended attributes of the device object. Finally, the file size and the alignment of the file's underlying buffer will be obtained and stored in the extended structure of the file's device information, and then a notification of successful opening will be returned.

[0052] When opening a file, you need to specify the file access permission as shared read, and obtain the file size and the alignment of the file's underlying buffer through ZwQueryInformationFile.

[0053] If the IRP_MJ_DEVICE_CONTROL request received from the upper layer is an operation to close a file, the driver will close the H handle in the extended information of the device object, release the file-related resources, restore the related parameters to their initial values, and set the completion status of the IRP.

[0054] Embodiment 3

[0055] This embodiment provides a specific implementation method. The technical problem to be solved by the present invention includes the following steps:

[0056] Things and steps that the R0 driver needs to handle:

[0057] Step 1: During initialization, the driver will first create a temporary directory F under the WindowsNT object manager namespace, and then create 26 disk-type devices under F through IoCreateDeviceSecure. When calling IoCreateDeviceSecure, you need to specify the security descriptor string "D:P(A; GA; SY)(A; GA; BA)(A; GA; BU)(A; GA; AU)(A; GA; IU)", and set the created device to read-only state. After each device is successfully created, you need to call KeInitializeEvent to initialize the event object E in DEVICE_EXTENSION. Event object E is used to notify the working thread that an event is triggered and the working thread enters the working state. At the same time, you need to call InitializeListHead to initialize a linked list object L, which is used to store IRP requests. The extended parameters of the device include the handle V of the volume object in the image, the file handle H, the device number N, the drive letter D, and the image file reading object.

[0058] Step 2: When creating a disk device, call PsCreateSystemThread to create a worker thread for each disk device. The initial state of each worker thread is waiting for the triggering of each event object created in step 1. In step 1, an event object is created by KeInitializeEvent. When this event object is not triggered, the created worker thread is in a waiting state. When the event object created in step 1 is triggered, this thread can continue to hang on to the subsequent operations.

[0059] Step 3. Specify IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL (these are all distribution routines of Windows kernel drivers. The macro here is actually a value, and each value corresponds to a function pointer in the array. These are all Windows kernel specifications) and the distribution function of the driver unloading routine. The preparation work of the driver is now completed.

[0060] Step 4. When the driver's IRP_MJ_DEVICE_CONTROL routine receives a volume mount message from the R3 layer (the R3 layer is the security layer of the CPU. There are 4 layers in the CPU: R0, R1, R2, and R3. The Windows kernel program runs in this layer, and the user-level program runs in the R3 layer), the IRP containing the parameters passed in by the R3 layer is inserted into the linked list L created in step 1, and KeSetEvent is called to trigger the event object E of the corresponding device created in step 1 (this event object E is created in step 1 and passed to the R3 layer, and here it is passed back to the R0 layer from the R3 layer).

[0061] Step 5: After the corresponding event object E in the thread created in step 1 is triggered in step 4, the working thread enters the working state (such as Figure 2As shown), first obtain the IRP request from the linked list L created in step 1. If it is a request to mount the image file, the corresponding image file is opened through the image file module according to the path and version information of the image file passed in by R3, and the corresponding version is found from the version chain of the image file, and the corresponding volume object is obtained from the corresponding version through the image file module. If successful, the handle of the volume object is stored in the volume object handle V of the extended information of the device object. If the image file opening fails, the error code of the reason for the failure is returned to the R3 layer and the current IRP is terminated. After success, the driver will create a drive letter for this device according to the drive letter parameter passed in by the R3 layer, so that this disk can be directly seen in the Windows Explorer, and accessing this drive letter is to access the data in the image file. If the drive letter is successfully created, it returns success to the R3 layer and ends the IRP. If the creation fails, it is necessary to close the opened image file and return the error code information of failure to the R3 layer. If the execution is successful up to this point, then there will be an additional drive letter specified by R3 in the Windows Explorer at this time. The user can open the volume like accessing a normal Windows disk, copy the data inside and run the program inside.

[0062] Step 6: If the driver receives a read message, the read message is delivered to the corresponding link L created by the corresponding device in step 1, and the event object E in the extended parameter of the corresponding device object is in the triggered state.

[0063] Step 7, after receiving the event of the event object E being triggered in step 6, the working thread of the corresponding device obtains the IRP request from the linked list L of the corresponding device, and determines whether it is a read operation. If it is a read operation, the starting position and the total number of bytes to be read are obtained from the parameters of the IRP, and the starting byte and the total bytes need to be converted into sectors. The starting sector is equal to the starting byte divided by the number of bytes in each sector, and the total sector is equal to the total number of bytes to be read divided by the number of bytes in each sector. If it is a write operation, it directly returns access denial because the image file is not writable.

[0064] Step eight, allocate a temporary cache memory space of type PagePool through ExAllocatePool according to the total number of bytes passed in by IRP, and determine whether V in the extended information is empty. If V in the extended information is not empty, read the data of the corresponding starting sector to the starting sector plus the total sector into the cache by calling the read interface of the mirror module. If V in the extended information is empty and the file handle H is not empty, then it is determined that the R3 layer needs to read the file data of the volume, and read the data into the buffer through ZwReadFile and using the file handle H. If successful, copy the data in the cache to the buffer passed in by R3, and notify the R3 layer of the success of the reading. If it fails, return the error code corresponding to the failure reason of the R3 layer, and finally release the temporary memory cache and set the IRP to the completion status.

[0065] If the IRP received in the driver is a write request, a write failure message will be directly returned in the IRP_MJ_WRITE routine, because image files are usually only readable and not writable.

[0066] If the driver receives an IRP from the upper layer to obtain the volume size, the driver returns the size information passed from R3 during mounting to Windows Explorer.

[0067] If the driver receives an IRP from the upper layer to obtain whether the volume is writable, the driver will directly return the STATUS_MEDIA_WRITE_PROTECTED message, indicating that the volume is not writable.

[0068] If the driver receives an IRP from the upper layer to update the partition, the driver returns the STATUS_MEDIA_WRITE_PROTECTED message, indicating that the volume is not writable, so no update operation can be performed on the volume.

[0069] If an uninstall IRP is received from an R3 layer application, the V object in the extended parameters of the corresponding device object is closed, and the drive letter of the corresponding device is deleted, so that the virtual drive letter in the Windows Explorer can be deleted.

[0070] If an IRP_MJ_DEVICE_CONTROL request is received from the upper layer and it is a request to open a file, the driver will first use the security attributes passed in by the R3 layer to simulate the access rights of the driver's current thread as having access rights at the R3 layer, and then open the file by calling ZwCreateFile. If the opening is successful, the file name and handle information will be stored in the extended attributes of the device object. When opening the file, the access rights of the file need to be specified as shared read, because files in the image file are not allowed to be modified. Finally, the file size and the alignment of the file's underlying buffer are obtained through ZwQueryInformationFile and stored in the extended structure of the file's device information, and a successful notification is returned to the R3 layer.

[0071] If an IRP_MJ_DEVICE_CONTROL request is received from the upper layer, and the request type is to close a file, the driver will close the H handle in the extended information of the device object, release the file-related resources, restore the related parameters to their initial values, and set the completion status of the IRP.

[0072] Steps for R3 Tier Application:

[0073] Step 1: The user obtains a version list of the image file according to the task or the path where the image file is located. The program displays the obtained version list to the user. The user selects the version to be mounted according to the version list displayed by the program. The program displays the volume information in the image file to the user according to the version selected by the user. The application displays the idle drive letter information of the current Windows system to the user. The user selects the volume to be mounted and specifies an idle drive letter for the volume to be displayed.

[0074] Step 2: The application passes the path of the image file selected by the user, the version to be mounted, the volume size, the volume ID, the password, the task name, the task GUID and other information to a device object created by R0 through control codes. After the call, the device object will receive a message to mount the volume, and the driver will execute the above mounting logic. If successful, a drive letter specified by the user will be seen in the Windows Explorer, and the user can access the image file data just like accessing a Windows local disk.

[0075] Explanation of professional terms:

[0076] IRP: IRP (I / O Request Packet) in Windows is a data structure used to represent input / output (I / O) operation requests. It is used to manage and track I / O requests of various device drivers. When an application or system needs to interact with a device (such as reading a file, sending data to a network device, etc.), the operating system creates an IRP to describe the request and then passes it to the appropriate device driver to perform the requested operation.

[0077] Volume: The highest level of organization in a file system is a volume. The file system resides on a volume. A volume contains at least one partition, which is a logical division of a physical disk. A volume that contains data present on one partition is called a simple volume, and a volume that contains data present on multiple partitions is called a multi-partition volume.

[0078] Event object: (Kernel Event) is a mechanism used in the operating system to handle asynchronous event notification and synchronization. It is mainly used to provide efficient I / O event notification and processing, allowing applications to perform asynchronous operations and event processing more effectively.

[0079] Handle: Handle is a commonly used term in computer science, usually used to represent a reference or identification of a resource or object, such as memory, files, graphical interface elements, etc. A handle can be regarded as an abstract identifier that uniquely identifies a specific resource.

[0080] Linked List: A linked list is a common data structure in computer science, used to store a series of elements, each element is called a node.

[0081] To solve the above problems, the main functional modules of the present invention include:

[0082] Image module: This module is mainly used to interpret image files, obtain file and volume information from image files, and provide the function of reading in sector mode.

[0083] Driver module: The driver mainly provides the virtual volume function and the function of accessing data in the image file in the driver mode by calling the image file module.

[0084] Interface module: a module that mainly provides interactive functions for users.

[0085] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0086] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for mounting a backup image as a Windows volume, characterized in that: The following steps are involved: Step S1, the driver is initialized; first, a temporary directory F is created under the Windows NT object manager namespace, and multiple disk devices are created under the temporary directory F. After the creation is successful, the event object E in DEVICE_EXTENSION is initialized. The event object E is used to notify the working thread that an event is triggered; Step S2, calling PsCreateSystemThread to create a working thread for the disk device, the initial state of the working thread is to wait for the triggering of the event object E; Step S3, specifying an IRP response sequence and a driver uninstallation routine for the driver; Step S4, waiting for the working thread to be triggered by the event object E. When the working thread is triggered by the event object E, the working thread enters the working state and processes the event object E accordingly.

2. A method for mounting a backup image as a Windows volume according to claim 1, characterized in that: In step S1, multiple disk-type devices are created under the temporary directory F as follows: disk-type devices are created through IoCreateDeviceSecure, and when calling IoCreateDevice Secure, the security descriptor string D:P(A;;GA;;;SY)(A;;GA;;;BA)(A;;GA;;;BU)(A;;GA;;;AU)(A;;GA;;;IU) needs to be specified, and the created device is set to read-only state.

3. A method for mounting a backup image as a Windows volume according to claim 2, characterized in that: After the device is successfully created, KeInitializeEvent is called to initialize the event object E; then a linked list object L is initialized by calling InitializeListHead. The linked list object is used to store IRP requests.

4. A method for mounting a backup image as a Windows volume according to claim 3, characterized in that: In step S4, when the working thread is triggered by the event object E to enter the working state, the processing includes the following steps: Step S401, determine whether the event object E is an end event, if yes, then end directly; if not, proceed to the next step; Step S402, determine whether the linked list is empty, if so, return to step S3, wait for event object E to trigger; if not, take out the IRP from the linked list; Step S403, determine whether the IRP is a read operation, if yes, process the read logic, and return to step S402, waiting for the next event object E to trigger; if no, proceed to the next step; Step S404, determine whether the IRP is a write operation; if yes, process the write logic and return to step S402 to wait for the next event object E to trigger; if no, proceed to the next step; Step S405, determine whether the IRP is a control code instruction, if so, process the control code instruction logic; if not, return a setting error, and return to step S402, waiting for the next event object E to be triggered.

5. A method for mounting a backup image as a Windows volume according to claim 4, characterized in that: In step S403, when processing a read operation, it is necessary to obtain the starting position and the total number of bytes to be read from the parameters of the IRP, and both the starting byte and the total bytes need to be converted into sectors, where the starting sector is equal to the starting byte divided by the number of bytes in each sector, and the total sectors are equal to the total number of bytes to be read divided by the number of bytes in each sector.

6. A method for mounting a backup image as a Windows volume according to claim 5, characterized in that: In step S404, the write logic is specifically processed as follows: a write failure message is directly returned in the IRP_MJ_WRITE routine.

7. A method for mounting a backup image as a Windows volume according to claim 6, characterized in that: In step S405, the control code instruction logic is specifically as follows: first determine whether the received control code instruction IRP_MJ_DEVICE_CONTROL request is a request to open a file or a request to close a file. If it is a request to open a file, it is processed through the file opening logic; if it is a request to close a file, it is processed through the file closing logic.

8. A method for mounting a backup image as a Windows volume according to claim 7, characterized in that: If the IRP_MJ_DEVICE_CONTROL request received from the upper layer is a request to open a file, the driver will first use the security attributes passed in by the R3 layer to simulate the access rights of the driver's current thread as having access rights, and then open the file by calling ZwCreateFile. If the file is opened successfully, the file name and handle information will be stored in the extended attributes of the device object. Finally, the file size and the alignment of the file's underlying buffer will be obtained and stored in the extended structure of the file's device information, and then a notification of successful opening will be returned.

9. A method for mounting a backup image as a Windows volume according to claim 8, characterized in that: When opening a file, you need to specify the file access permission as shared read, and obtain the file size and the alignment of the file's underlying buffer through ZwQueryInformationFile.

10. A method for mounting a backup image as a Windows volume according to claim 9, characterized in that: If the IRP_MJ_DEVICE_CONTROL request received from the upper layer is an operation to close a file, the driver will close the H handle in the extended information of the device object, release the file-related resources, restore the related parameters to their initial values, and set the completion status of the IRP.

Images