MFT fragment recovery method, terminal device and storage medium

Abstract

The present invention relates to a method, terminal device, and storage medium for recovering MFT fragments. This method identifies all MFT file fragments by combining file record characteristics with MFT data storage and allocation properties. Furthermore, based on characteristics such as file IDs and unique cluster sizes, MFT file fragments are classified and reorganized, ultimately achieving MFT fragment recovery. This method provides an effective means for recovering data in complex situations, such as multiple partition formatting and data overwriting caused by erroneous partition expansion.

Description

Technical Field

[0001] The present invention relates to the field of file technology, and in particular to a method for recovering MFT fragments, a terminal device, and a storage medium. Background Art

[0002] The MFT file is a crucial file used by the NTFS file system to store metadata for all files. When the file system crashes or is formatted, it is necessary to reconstruct and restore the entire file system. As a metadata file, the MFT file is constantly updated and written to as long as the system is running, so it often exhibits a certain degree of fragmentation.

[0003] Currently, MFT file recovery primarily relies on searching for file record characteristics, organizing all file records into a single file and then recovering data based on this file. However, in complex scenarios, such as multiple formatting and accidental partition expansion leading to data overwrite, the searched file records may belong to multiple file systems. Simple search and recovery can lead to problems such as a disordered file directory structure and inaccurate file content location. Summary of the Invention

[0004] In order to solve the above problems, the present invention proposes a method for recovering MFT fragments, a terminal device, and a storage medium.

[0005] The specific plan is as follows:

[0006] A method for recovering MFT fragments includes the following steps:

[0007] S1: Get the partition size PartitionSize of the disk and set the current search position CurrentOffset to 0;

[0008] S2: Determine whether the current search position CurrentOffset is greater than or equal to the partition size PartitionSize. If so, proceed to S9; otherwise, proceed to S3.

[0009] S3: Read a 1024-byte data block from the current search position CurrentOffset of the disk partition and determine whether the read 1024-byte data block belongs to the MFT file record block. If not, update the value of the current search position CurrentOffset by adding 512 to its original value and return to S2; otherwise, enter S4;

[0010] S4: Set the fragment starting position FragmentStart to the current search position CurrentOffset;

[0011] S5: Set the fragment end position FragmentEnd to the current search position CurrentOffset+1023, and update the current search position CurrentOffset to increase the value by 1024 based on its original value;

[0012] S6: Determine whether the current search position CurrentOffset is greater than or equal to the partition size PartitionSize. If so, proceed to S8; otherwise, proceed to S7.

[0013] S7: Read a 1024-byte data block from the current search position CurrentOffset of the disk partition, and determine whether the read 1024-byte data block belongs to the MFT file record block. If so, return to S5; otherwise, enter S8;

[0014] S8: Add the fragment start position FragmentStart and the fragment end position FragmentEnd as an element to the fragment set FR, update the current search position CurrentOffset to increase 512 based on its original value, and return to S2;

[0015] S9: Parse each fragment in the fragment set FR according to the MFT file record structure, and generate a file record set sequence FSS according to the file record set FS corresponding to each fragment after parsing;

[0016] S10: Determine whether the fragment set FR is empty. If so, end; otherwise, enter S11;

[0017] S11: Select any element from the fragment set FR and cut it into the file fragment set FRTmp, and delete the file record corresponding to the element from the file record set sequence FSS;

[0018] S12: Determine whether there is an element in the file fragment set FRTmp such that it satisfies the requirement of belonging to the same MFT file as another element in the fragment set FR. If so, proceed to S13; if not, reassemble the elements in the file fragment set FRTmp into one MFT file, clear the file fragment set FRTmp, and return to S10.

[0019] S13: Cut the other element in the fragment set FR into the file fragment set FRTmp, and delete the file record corresponding to the other element from the file record set sequence FSS, and return to S12.

[0020] Furthermore, the method for determining whether the read 1024-byte data block belongs to the MFT file record block is:

[0021] Parse the data block DataBuff according to the NTFS file record structure to obtain the MFT identifier MFTMagic, the file record time length FileRecordRealLenth, and the file record allocation length FileRecordAllocLenth. If the following three conditions are met at the same time, the data block DataBuff is determined to belong to the MFT file record block.

[0022] Condition 1: DataBuff

[30] is equal to DataBuff

[1022] , and DataBuff

[31] is equal to DataBuff

[1023] ; where DataBuff[i] represents the i-th byte in the data block DataBuff, and i is an integer between 1 and 1024;

[0023] Condition 2: The MFT identifier MFTMagic is FILE;

[0024] Condition three: The file record time length FileRecordRealLenth is less than or equal to the file record allocation length FileRecordAllocLenth, and the file record allocation length FileRecordAllocLenth is equal to 1024.

[0025] Furthermore, the method for determining whether two fragments belong to the same MFT file is as follows: when the following three conditions are met at the same time, the two fragments are determined to belong to the same MFT file:

[0026] Condition 1: Select elements m and n from the two file record sets corresponding to the two fragments, whose file physical size PhysicalSize is greater than 512 and whose file data cluster chain CList is not empty. Elements m and n satisfy: the file physical size PhysicalSize of element m m The ratio of the total cluster data occupied by all linked list elements in the file data cluster chain CList corresponding to element m is equal to the file physical size PhysicalSize of element n n The ratio of the total cluster data occupied by all linked list elements in the file data cluster chain CList corresponding to element n;

[0027] Condition 2: There are no elements with the same file ID in the two file record sets;

[0028] Condition three: For any element in the two file record sets, based on its parent directory ID, find out whether there is an element with a file ID equal to the parent directory ID from the two file record sets. If so, the file type of the element should be a folder type.

[0029] Furthermore, a method for reorganizing the elements in the file fragment set FRTmp into an MFT file is: reorganizing the elements in the file fragment set FRTmp in the order of their offsets in the disk partition.

[0030] A terminal device for recovering MFT fragments includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the MFT fragment recovery method described above are implemented in an embodiment of the present invention.

[0031] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method for recovering MFT fragments according to an embodiment of the present invention.

[0032] This invention employs the above technical solution, identifying all MFT file fragments by combining file record characteristics with the MFT data storage and allocation characteristics. It then classifies and reorganizes MFT file fragments based on characteristics such as file IDs (also known as MFT numbers) and unique cluster sizes, ultimately achieving MFT fragment recovery. This method provides an effective means for data recovery in complex situations, such as when a partition has been formatted multiple times or when data has been overwritten due to incorrect partition expansion (i.e., when there are multiple partitions). BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 Shown is a flow chart of embodiment 1 of the present invention. DETAILED DESCRIPTION

[0034] To further illustrate various embodiments, the present invention provides accompanying drawings. These drawings form part of the present disclosure and are primarily used to illustrate the embodiments and, in conjunction with the relevant description in the specification, to explain the operating principles of the embodiments. By referring to these drawings, those skilled in the art will be able to understand other possible implementations and the advantages of the present invention.

[0035] The present invention will now be further described with reference to the accompanying drawings and specific embodiments.

[0036] Example 1:

[0037] NTFS files store all file metadata in the form of file records in the MFT file. The MFT file consists of file records, each of which occupies 1024 bytes. A file record contains information such as the file's name, type, whether it has been deleted, size, physical size, data cluster chain, time, file ID, and parent directory ID. Furthermore, to enable fast indexing, each folder also contains cluster chain information pointing to an index buffer. The index buffer stores information such as the folder ID (i.e., the parent directory ID of the child file) and the file name, file time, and file ID of the child files under the folder.

[0038] The principle of MFT fragment recovery in this embodiment mainly relies on the following characteristics of the NTFS file system, where characteristics 1-2 are used to search and determine MFT fragments, and characteristics 3-5 are used to reassemble MFT fragments. The specific characteristics are as follows:

[0039] 1. An MFT file is composed of a series of file records. Each file record has certain header characteristics and data structure, and file records always appear at the beginning of a sector. Therefore, based on the header characteristics combined with structure verification, it is possible to accurately determine whether the beginning of a sector is the start of an MFT file record.

[0040] 2. In order to avoid too much fragmentation in the MFT, the MFT file space is generally allocated in a continuous cluster allocation method. Therefore, multiple MFT file records in a continuous space generally belong to the same MFT file.

[0041] 3. NTFS files use file IDs and parent directory IDs to construct the file system. File ID values ​​are unique within the same file system. Therefore, when reassembling MFT fragments, duplicate file IDs (excluding deleted files) must not occur.

[0042] 4. The cluster size value is unique within the same file system. Therefore, when reorganizing the MFT fragments, file records with different cluster sizes cannot appear (the cluster size can be calculated based on the file records).

[0043] 5. The file type obtained by parsing the file record pointed to by the parent directory ID of a file must be a folder type. Therefore, when reorganizing MFT fragments, if the parsing results of the file records in two fragments can form a parent-child directory relationship, the file record whose parent directory ID points to a file is not allowed.

[0044] Based on the above principles, an embodiment of the present invention provides a method for recovering MFT fragments, such as Figure 1 As shown, the method includes the following steps:

[0045] S1: Get the partition size PartitionSize of the disk and set the current search position CurrentOffset to 0;

[0046] S2: Determine whether the current search position CurrentOffset is greater than or equal to the partition size PartitionSize. If so, proceed to S9; otherwise, proceed to S3.

[0047] S3: Read a 1024-byte data block from the current search position CurrentOffset of the disk partition and determine whether the read 1024-byte data block belongs to the MFT file record block. If not, update the value of the current search position CurrentOffset by adding 512 to its original value and return to S2; otherwise, enter S4;

[0048] S4: Set the fragment starting position FragmentStart to the current search position CurrentOffset;

[0049] S5: Set the fragment end position FragmentEnd to the current search position CurrentOffset+1023, and update the current search position CurrentOffset to increase the value by 1024 based on its original value;

[0050] S6: Determine whether the current search position CurrentOffset is greater than or equal to the partition size PartitionSize. If so, proceed to S8; otherwise, proceed to S7.

[0051] S7: Read a 1024-byte data block from the current search position CurrentOffset of the disk partition, and determine whether the read 1024-byte data block belongs to the MFT file record block. If so, return to S5; otherwise, enter S8;

[0052] S8: Add the fragment start position FragmentStart and the fragment end position FragmentEnd as an element to the fragment set FR, update the current search position CurrentOffset to increase 512 based on its original value, and return to S2;

[0053] S9: Parse each fragment in the fragment set FR according to the MFT file record structure, and generate a file record set sequence FSS according to the file record set FS corresponding to each fragment after parsing;

[0054] S10: Determine whether the fragment set FR is empty. If so, end; otherwise, enter S11;

[0055] S11: Select any element from the fragment set FR and cut it into the file fragment set FRTmp, and delete the file record corresponding to the element from the file record set sequence FSS;

[0056] S12: Determine whether there is an element in the file fragment set FRTmp such that it satisfies the requirement of belonging to the same MFT file as another element in the fragment set FR. If so, proceed to S13; if not, reassemble the elements in the file fragment set FRTmp into one MFT file, clear the file fragment set FRTmp, and return to S10.

[0057] S13: Cut the other element in the fragment set FR into the file fragment set FRTmp, and delete the file record corresponding to the other element from the file record set sequence FSS, and return to S12.

[0058] The elements in the fragment set FR are file fragments. In this embodiment, the i-th element fr i The content includes two properties: the fragment starting position FragmentStart and the fragment ending position FragmentEnd.

[0059] The element content in the file record set sequence FSS is the file record set FS. The element content in each file record set FS is the file record of each file, specifically including: file name FileName, file type FileType, whether to delete IsDelete, file physical size PhysicalSize, file data cluster chain CList (each element in the list contains: cluster start CStart and cluster number CNumber), file ID FileID and parent directory ID ParentFileID and other attributes.

[0060] The method for determining whether the read 1024-byte data block belongs to the MFT file record block in step S3 is:

[0061] Parse the data block DataBuff according to the NTFS file record structure to obtain the MFT identifier MFTMagic, the file record time length FileRecordRealLenth, and the file record allocation length FileRecordAllocLenth. If the following three conditions are met at the same time, the data block DataBuff is determined to belong to the MFT file record block.

[0062] Condition 1: DataBuff

[30] is equal to DataBuff

[1022] , and DataBuff

[31] is equal to DataBuff

[1023] ; where DataBuff[i] represents the i-th byte in the data block DataBuff, and i is an integer between 1 and 1024;

[0063] Condition 2: The MFT identifier MFTMagic is FILE;

[0064] Condition three: The file record time length FileRecordRealLenth is less than or equal to the file record allocation length FileRecordAllocLenth, and the file record allocation length FileRecordAllocLenth is equal to 1024.

[0065] The method for determining whether two fragments belong to the same MFT file in step S12 is as follows: when the following three conditions are met at the same time, it is determined that the two fragments belong to the same MFT file, that is, they can be directly spliced:

[0066] Condition 1: Select elements m and n from the two file record sets corresponding to the two fragments, whose file physical size PhysicalSize is greater than 512 and whose file data cluster chain CList is not empty. Elements m and n satisfy: the file physical size PhysicalSize of element m m The ratio of the total cluster data occupied by all linked list elements in the file data cluster chain CList corresponding to element m is equal to the file physical size PhysicalSize of element n n The ratio of the total cluster data occupied by all linked list elements in the file data cluster chain CList corresponding to element n;

[0067] Condition 2: There are no elements with the same file ID in the two file record sets, that is, there is no element in one file record set with the same file ID as the element in the other file record set;

[0068] Condition three: For any element in the two file record sets, based on its parent directory IDParentFileID, find out from the two file record sets whether there is an element with file ID FileID equal to ParentFileID. If it exists, the file type of the element should be a folder type.

[0069] In this embodiment, the method for reorganizing the elements in the file fragment set FRTmp into an MFT file is: reorganizing the elements in the file fragment set FRTmp according to the size order of their offsets in the disk partition, such as in ascending order.

[0070] The above method proposed in the embodiment of the present invention is an effective means to cope with NTFS recovery in complex scenarios. The method can automatically identify MFT fragments and automatically classify and reorganize MFT fragments from different file systems based on data storage characteristics and internal structure characteristics, ultimately achieving accurate recovery of MFT fragments, effectively compensating for the inaccurate recovery problem that exists in existing means when dealing with complex recovery scenarios.

[0071] Example 2:

[0072] The present invention also provides an MFT fragment recovery terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the above-mentioned method embodiment of the first embodiment of the present invention are implemented.

[0073] Furthermore, as an executable solution, the MFT fragment recovery terminal device can be a computing device such as a desktop computer, a notebook, a PDA, and a cloud server. The MFT fragment recovery terminal device may include, but is not limited to, a processor and a memory. Those skilled in the art will understand that the composition structure of the above-mentioned MFT fragment recovery terminal device is only an example of the MFT fragment recovery terminal device and does not constitute a limitation on the MFT fragment recovery terminal device. It may include more or fewer components than the above-mentioned components, or a combination of certain components, or different components. For example, the MFT fragment recovery terminal device may also include input and output devices, network access devices, buses, etc., which are not limited in the embodiments of the present invention.

[0074] Furthermore, as an executable solution, the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the MFT fragment recovery terminal device, and utilizes various interfaces and lines to connect various parts of the entire MFT fragment recovery terminal device.

[0075] The memory can be used to store the computer program and / or module, and the processor realizes various functions of the MFT fragment recovery terminal device by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required for a function; the data storage area can store data created based on the use of the mobile phone, etc. In addition, the memory can include a high-speed random access memory and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0076] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method in the embodiment of the present invention are implemented.

[0077] If the module / unit integrated in the MFT fragment recovery terminal device is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device that can carry the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM) and software distribution medium, etc.

[0078] Although the present invention has been particularly shown and described in conjunction with preferred embodiments, it will be understood by those skilled in the art that various changes in form and details may be made to the present invention without departing from the spirit and scope of the invention as defined in the appended claims, and all such changes are within the scope of protection of the present invention.

Claims

1. A method for recovering MFT fragments, characterized in that: The following steps are involved: S1: Get the partition size PartitionSize of the disk and set the current search position CurrentOffset to 0; S2: Determine whether the current search position CurrentOffset is greater than or equal to the partition size PartitionSize. If so, proceed to S9; otherwise, proceed to S3. S3: Read a 1024-byte data block from the current search position CurrentOffset of the disk partition and determine whether the read 1024-byte data block belongs to the MFT file record block. If not, update the value of the current search position CurrentOffset by adding 512 to its original value and return to S2; otherwise, enter S4; S4: Set the fragment starting position FragmentStart to the current search position CurrentOffset; S5: Set the fragment end position FragmentEnd to the current search position CurrentOffset+1023, and update the current search position CurrentOffset to increase the value by 1024 based on its original value; S6: Determine whether the current search position CurrentOffset is greater than or equal to the partition size PartitionSize. If so, proceed to S8. Otherwise, go to S7; S7: Read a 1024-byte data block from the current search position CurrentOffset of the disk partition, and determine whether the read 1024-byte data block belongs to the MFT file record block. If so, return to S5; Otherwise, go to S8; S8: Add the fragment start position FragmentStart and the fragment end position FragmentEnd as an element to the fragment set FR, update the current search position CurrentOffset to increase 512 based on its original value, and return to S2; S9: Parse each fragment in the fragment set FR according to the MFT file record structure, and generate a file record set sequence FSS according to the file record set FS corresponding to each fragment after parsing; S10: Determine whether the fragment set FR is empty. If so, end. Otherwise, go to S11; S11: Select any element from the fragment set FR and cut it into the file fragment set FRTmp, and delete the file record corresponding to the element from the file record set sequence FSS; S12: Determine whether there is an element in the file fragment set FRTmp such that it satisfies the requirement of belonging to the same MFT file as another element in the fragment set FR. If so, proceed to S13; if not, reassemble the elements in the file fragment set FRTmp into one MFT file, clear the file fragment set FRTmp, and return to S10. S13: Cut the other element in the fragment set FR into the file fragment set FRTmp, and delete the file record corresponding to the other element from the file record set sequence FSS, and return to S12.

2. The method for recovering MFT fragments according to claim 1, wherein: The method to determine whether the read 1024-byte data block belongs to the MFT file record block is: Parse the data block DataBuff according to the NTFS file record structure to obtain the MFT identifier MFTMagic, the file record time length FileRecordRealLenth, and the file record allocation length FileRecordAllocLenth. If the following three conditions are met at the same time, the data block DataBuff is determined to belong to the MFT file record block. Condition 1: DataBuff[30] is equal to DataBuff[1022], and DataBuff[31] is equal to DataBuff[1023]; where DataBuff[i] represents the i-th byte in the data block DataBuff, and i is an integer between 1 and 1024; Condition 2: The MFT identifier MFTMagic is FILE; Condition three: The file record time length FileRecordRealLenth is less than or equal to the file record allocation length FileRecordAllocLenth, and the file record allocation length FileRecordAllocLenth is equal to 1024.

3. The method for recovering MFT fragments according to claim 1, wherein: The method to determine whether two fragments belong to the same MFT file is: when the following three conditions are met at the same time, the two fragments are judged to belong to the same MFT file: Condition 1: Select elements m and n from the two file record sets corresponding to the two fragments, whose file physical size PhysicalSize is greater than 512 and whose file data cluster chain CList is not empty. Elements m and n satisfy: the file physical size PhysicalSize of element m m The ratio of the total cluster data occupied by all linked list elements in the file data cluster chain CList corresponding to element m is equal to the file physical size PhysicalSize of element n n The ratio of the total cluster data occupied by all linked list elements in the file data cluster chain CList corresponding to element n; Condition 2: There are no elements with the same file ID in the two file record sets; Condition three: For any element in the two file record sets, based on its parent directory ID, find out whether there is an element with a file ID equal to the parent directory ID from the two file record sets. If so, the file type of the element should be a folder type.

4. The method for recovering MFT fragments according to claim 1, wherein: The method for reorganizing the elements in the file fragment set FRTmp into an MFT file is: reorganizing the elements in the file fragment set FRTmp in the order of their offsets in the disk partition.

5. A terminal device for recovering MFT fragments, characterized by: The method comprises a processor, a memory, and a computer program stored in the memory and running on the processor, wherein the processor implements the steps of the MFT fragment recovery method according to any one of claims 1 to 4 when executing the computer program.

6. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the MFT fragment recovery method according to any one of claims 1 to 4 are implemented.

Images