CN110309019B - Method for rapidly recovering and extracting deleted files in APFS (advanced persistent file system) - Google Patents
Method for rapidly recovering and extracting deleted files in APFS (advanced persistent file system) Download PDFInfo
- Publication number
- CN110309019B CN110309019B CN201910591370.XA CN201910591370A CN110309019B CN 110309019 B CN110309019 B CN 110309019B CN 201910591370 A CN201910591370 A CN 201910591370A CN 110309019 B CN110309019 B CN 110309019B
- Authority
- CN
- China
- Prior art keywords
- apfs
- container
- block
- volume
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Library & Information Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a method for quickly recovering and extracting deleted files in an APFS (advanced persistent file system), which is characterized by comprising the following steps of: s100: loading a magnetic disk and reading the sector 0 information of the magnetic disk; s200: detecting the disk data and judging whether the disk data is data in an APFS file system format, if so, executing a step S300, otherwise, executing a step S100; s300: analyzing APFS container data; s400: acquiring child node records under each file path/. Tracks/501 of the APFS container, judging whether record information describing file path/. Tracks/501 objects exists, if so, executing a step S500, otherwise, executing a step S300; s500: reading child node record information under each volume path/. Tracks/501; s600: judging whether the storage space of the child node of the volume path/trains/501 is distributed, if so, executing the step S800, otherwise, executing the step S700; s700: addressing and extracting data according to the address of the storage block of the child node object; s800: and (4) classifying and extracting data according to the storage condition and the coverage condition of the storage space of the child nodes of the Trashes/501.
Description
Technical Field
The invention belongs to the field of electronic data recovery and evidence obtaining, and relates to a method for quickly recovering and extracting a deleted file in an APFS (advanced persistent file system).
Background
APFS is an abbreviation of Apple File System, and is a brand-new File format formally released by Apple inc at the WWDC of 2016, 6, month, and 14 days to replace the currently used HFS + File System, and is characterized by "optimizing flash/SSD storage and using encryption as a main function", using "unique copy-on-write (COW-on-write) design" in I/O association, and optimizing performance on the basis of ensuring reliability. The core of the system is an encryption function, which provides a uniform encryption method for each device under the apple flag. The system comprises a multi-key encryption function, a key for each file is arranged in the system, and independent keys are arranged for sensitive metadata.
Due to the unique file format and the high encryption function of the APFS, deleted files in the APFS are difficult to recover and extract. Therefore, no method for quickly recovering and extracting the deleted files in the APFS exists in the prior art, which causes great difficulty in electronic data recovery and evidence obtaining of the APFS. Therefore, a method for quickly recovering and extracting the deleted file in the APFS is urgently needed to make up for the defect of difficulty in electronic data recovery and evidence collection of the APFS.
Disclosure of Invention
Aiming at the problem of the deficiency of the prior art, the invention provides a method for quickly recovering and extracting a deleted file in an APFS (advanced persistent file system): and rapidly recovering and extracting the deleted files/folders by analyzing the B-tree node record information of each volume contained in the paths/traces/501/of the volumes of the APFS container, thereby achieving the purpose of recovering and extracting the deleted files in the APFS.
In the APFS container, the storage data uses a B-tree data structure. The B-tree is a self-balancing tree which can keep data in order, and the data structure can enable actions of searching data, sequentially accessing, inserting data and deleting to be completed in logarithmic time. Therefore, the data in the APFS file system APFS container can be quickly operated.
For ease of description, the present invention may include the following terms:
an APFS container: dividing a plurality of logic parts on a disk, wherein each logic part for storing APFS file system data is called an APFS container;
b-tree: the data structure is used for carrying out storage management on file information in the file volumes;
logarithmic time: refers to the time taken to perform a series of operations according to a B-tree data structure with a time complexity of O (logN);
a parcel: one or more physical parts divided in one APFS container; all volumes may share free space in the APFS container;
block (2): an APFS container is equally divided into a plurality of storage units, each storage unit being called a block;
bitmap structure BMS: the usage of all blocks in the APFS container is managed (e.g., 0: indicating unallocated; 1: indicating allocated usage).
The invention application comprises the following steps:
s100: loading disk data: loading the disk and reading the 0 sector information of the disk, wherein the 0 sector information comprises:
the APFS storage system comprises an APFS main super block MSB with a mark of 'NXSB', an ID of an APFS copy-on-write COW (copy-on-write) of an APFS container, APFS container super block information, APFS container description block information, an APFS bitmap manager block address, an APFS volume index block address and an APFS volume ID, wherein the APFS main super block MSB is used for describing APFS disk description information; the mark 'NXSB' is used for judging whether the disk data is APFS file system format data or not; the ID of the copy COW is used for determining the sequence of the update data in the APFS container when the APFS container is written; the APFS container superblock information and the APFS container description block information are used for determining the data storage state in the APFS container when the APFS container copies the ID of the COW at different writing times; the APFS bitmap manager is used for storing the distribution use condition of all blocks of an APFS container; the APFS volume index block is used for addressing all volume description information blocks in an APFS container; the APFS volume ID is used for describing all APFS volume IDs currently contained in the APFS container;
s200: detecting the disk data and judging whether the disk data is data in an APFS file system format, if so, executing a step S300, otherwise, executing a step S100;
s300: parsing the APFS container data: analyzing each volume of the APFS container, each volume index block address and each APFS volume ID;
s400: acquiring child node records under each file path/. Tracks/501 of the APFS container, judging whether record information describing file path/. Tracks/501 objects exists, if so, executing a step S500, otherwise, executing a step S300;
s500: reading child node record information under each volume path/. Tracks/501: reading child node record information under a volume path/. Tracks/501 one by one, wherein the record information comprises child node ID, child node object timestamp information, child node object name, child node object type, child node object storage starting block address and byte length of a child node object;
s600: judging whether the storage space of the child node of the volume path/. Tracks/501 is distributed, if so, executing the step S800, otherwise, executing the step S700;
s700: addressing and extracting data according to the address of the child node object storage block;
s800: data is extracted by classification according to storage conditions and covering conditions of storage space of a file path/. Tracks/501 child nodes, wherein the storage conditions comprise full allocation and partial allocation, and the covering conditions comprise full covering and uncovering.
Preferably, the specific steps of step S400 are as follows:
s401: reading the main superblock MSB of the APFS container: reading the sector information No. 0 of the APFS container, wherein the sector information comprises the block size of the APFS container, the ID copied when the APFS container is written, the block address description of an APFS container bitmap manager, the block address of an index of an APFS container file volume and the ID of the APFS container APFS file volume;
s402: addressing a volume checkpoint superblock VCSB according to the APFS container volume index block address: acquiring a file root block according to the file index block address of the main super block MSB, wherein the file root block comprises all APFS file IDs and file block addresses in the APFS container;
s403: reading B-tree structure information of the file volume: traversing all the volume information of the volume root block, addressing and reading the volume check point super block VCSB according to a volume block address, wherein the volume check point super block VCSB comprises an APFS volume ID, the number of allocated blocks of a volume, a volume B-tree object mapping block address, a volume B-tree root node ID and a block address of a volume B-tree interval block extntblock;
s404: according to the B-tree structure information of the volume, the node block where the path/. Tracks/501 of the volume is located is addressed, the B-tree node block information of the volume is traversed, whether the current B-tree node block has record information describing the path/. Tracks/501 object of the volume is judged, if yes, step S500 is executed, and if not, step S300 is executed.
Preferably, the specific steps of step S600 are as follows:
s601: judging the type of a child node object of a volume path/. Tracks/501: reading the record information of the sub-nodes of the volume path/. Tracks/501 one by one, judging whether each sub-node object type is a folder, if so, executing a step S602, otherwise, executing a step S603, if not, executing a step S603, wherein the sub-node object type is a file;
s602: acquiring child node contents of the folder nodes: traversing all B-tree node description information of the volume according to the folder node ID, reading child nodes of the folder node, judging whether the child node object type of the folder node is a folder, if so, executing step S602, otherwise, executing step S603;
s603: acquiring node object storage information: acquiring current node object storage information including a node ID, a node object name, a node timestamp, a node object storage start block address and a node object byte length according to different node record types;
s604: judging whether the storage space of the node object is allocated: and acquiring the block address information of the node storage space, reading a block allocation information table of an APFS (advanced persistent storage) container bitmap manager, acquiring an allocation record identifier of the storage space of the current child node object, executing step S700 if the allocation record identifier is not allocated, otherwise, executing step S800 if the allocation record identifier is allocated.
Preferably, the specific steps of step S800 are as follows:
s801: acquiring current storage object information in a storage space of a child node of a volume path/. Tracks/501: acquiring object description information of current storage data in the allocated storage space, wherein the object description information comprises an object ID of the current storage data, a storage start block address of a child node object and a byte length of the child node object;
s802: judging whether the current storage space is completely distributed, if so, executing a step S803, otherwise, indicating that the current storage space is partially distributed, and executing a step S805;
s803: judging whether the data in the current block is completely covered, if so, executing the step S400, otherwise, executing the step S804;
s804: extracting the uncovered data in the current block, and ending the process;
s805: judging whether the current block in the current storage space is distributed, if so, executing step S806, otherwise, executing step S807;
s806: after repeating steps S803 and S804, step S808 is executed;
s807: extracting data of unallocated blocks in the current storage space according to the storage starting block address of the child node object and the byte length of the child node object;
s808: combining the data of the allocated blocks in the current storage space extracted in step S806 with the data of the unallocated blocks in the current storage space extracted in step S807 to obtain the data in the case that the current storage space is partially allocated, and ending the flow.
The method has the advantages of solving the technical problem that no method for quickly recovering and extracting the deleted file in the APFS exists in the prior art, and having the following advantages:
1. rapidly judging whether the disk data is APFS file system data or not;
2. and determining the deleted file information of the file and realizing the recovery and extraction of deleted data according to the child node record content of the APFS container file path/. Traches/501.
3. Child node record information of the Trashes/501 correctly distinguishes the object type and the coverage state.
Drawings
FIG. 1 is a diagram illustrating a data structure of a B-tree block structure according to the present invention;
FIG. 2 is a general flow chart of the method provided by the present invention;
fig. 3 is a flowchart for acquiring child node records under each volume path/. Tracks/501 of the APFS container and determining whether record information describing an object of the volume path/. Tracks/501 exists in the method provided by the present invention;
FIG. 4 is a flowchart illustrating the method of determining whether a storage space of a child node of a volume path/tracks/501 is allocated;
FIG. 5 is a flowchart of the method for classifying and extracting data according to the present invention.
Detailed Description
The invention provides a data recovery method by using a/Traches/501 folder of each volume of an APFS file system APFS container, which can quickly and effectively recover and extract data in the APFS container volumes, and the invention is further explained by combining the attached drawings and the embodiment.
The data structure diagram of B-tree block structure of APFS is shown in FIG. 1.
Fig. 2 shows a general flow chart of the method provided by the present invention.
As shown in fig. 2, the method of the present invention comprises the steps of:
s100: loading disk data: loading a disk and reading 0 sector information of the disk, wherein the 0 sector information comprises:
the APFS file system comprises an APFS main super block MSB with a mark of 'NXSB', an ID of an APFS copy-on-write COW, APFS container super block information, APFS container description block information, an APFS bitmap manager block address, an APFS file index block address and an APFS file ID, wherein the APFS main super block MSB is used for describing APFS disk description information; the mark 'NXSB' is used for judging whether the disk data is APFS file system format data or not; copying the ID of the COW when the APFS container is written to determine the sequence of updating data in the APFS container; the APFS container superblock information and the APFS container description block information are used for determining the data storage state in the APFS container when the APFS container copies the ID of the COW in different writing processes; the APFS bitmap manager is used for storing the distribution use condition of all blocks of the APFS container; the APFS file index block is used for addressing all file description information blocks in the APFS container; the APFS volume ID is used for describing all APFS volume IDs currently contained in the APFS container;
s200: detecting the disk data and judging whether the disk data is data in an APFS file system format, if so, executing a step S300, otherwise, executing a step S100; when an APFS file system initializes a disk, writing a mark 'NXSB' into a 0x20 address of a0 sector of an APFS container, wherein the byte length of the mark is 4 bytes; specifically, a hexadecimal number 0x4E585352 (i.e., "NXSB") represented by ASCII code is written in a 0x20 address of a sector 0 of the APFS container, which has a byte length of 4 bytes; if the continuous 4 bytes of content starting from the 0x20 address is detected to be 0x4E585352, that is, the disk data is in the APFS file system format.
S300: parsing the APFS container data: analyzing each volume of the APFS container, each volume index block address and each APFS volume ID, specifically,
parsing records of the MSB (Main Super Block) of the Main superblock of the APFS container, and parsing the index Block address of the volume of the APFS container recorded therein. The block address of the APFS container volume index block is stored at offset addresses 0xA0 to 0xA7 of a main super block MSB of the APFS container, and the physical address = index block address value of the APFS container volume index block in the APFS container is calculated according to the value;
the block addresses that record the APFS container volume root block in the index block are stored at 0x30 to 0x37 offset locations of the index block. In a file root block, according to the data structure diagram of fig. 1, calculating an information offset position of each record in the file root block, including a key area and a data area, where the offset position of the key area = a block header byte length + a table index record offset value in the block; the offset location of the data area = block byte size-table tail byte length-table index record offset value in the block, resulting in the block address of all APFS Volume IDs, volume Checkpoint superblocks VCSB (Volume Checkpoint Superblock) contained by the APFS container.
S400: acquiring child node records under each file path/. Tracks/501 of the APFS container, judging whether record information describing a file path/. Tracks/501 object exists, if so, executing a step S500, otherwise, executing a step S300, wherein the specific steps of the step S400 are as follows:
s401: reading the main superblock MSB of the APFS container: reading sector information No. 0 of an APFS container, wherein the sector information includes the block size of the APFS container, the ID copied when the APFS container is written, the block address description of an APFS container bitmap manager, the block address of an index of a volume of the APFS container and the ID of the volume of the APFS container;
s402: the volume checkpoint superblock VCSB is addressed according to the APFS container volume index block address: acquiring a file root block according to the file index block address of the main super block MSB, wherein the file root block comprises all APFS file IDs and file block addresses in an APFS container;
specifically, the starting position of the main superblock MSB of the APFS container is shifted backward by 0xA0 bytes and the content of consecutive 8 bytes is read as a volume index block address, and the offset position of the volume index block in the APFS container is calculated as = volume index block address × APFS container block size.
And with the starting position of the index block shifted backward by 0x30 bytes and the content of continuous 8 bytes read as the root block address of the volume, calculating the offset position of the root block of the volume in the APFS container = the root block address of the volume. The block structure shown in fig. 1 is adopted in the volume root block, and records all APFS volume IDs and block addresses of the volumes contained in the APFS container.
S403: reading the B-tree structure information of the file volume:
traversing all of the volume information of the volume root block, addressing and reading the volume checkpoint superblock VCSB according to the volume block address, where 0x20 bytes are offset backwards from the starting address of the VCSB and a consecutive 4 bytes of content are read, which if represented as a VCSB is the hexadecimal number 0x41505342 (i.e., "APSB") represented in ASCII code, the tag is used to identify the VCSB.
The volume checkpoint super block VCSB comprises an APFS volume ID, the number of allocated blocks of the volume, a volume B-tree object mapping block address, a volume B-tree root node ID and a block address of a volume B-tree interval block extentblock, wherein the starting address of the volume checkpoint super block VCSB is shifted backwards by 0x80 bytes, continuous 8-byte content is read to serve as the volume B-tree object mapping block address, and the volume checkpoint super block VCSB is stored in a small-end format; shifting the starting address of the volume checkpoint superblock VCSB backward by 0x88 bytes and reading the content of continuous 8 bytes as a volume B-tree root node ID, which is stored in a small-end format;
and determining the B-tree node block where the volume path/. Traches/501 node is located according to the ID of the B-tree root node of the volume and the block address of the B-tree object mapping. According to the data structure diagram shown in fig. 1, all child node record information contained in a volume path/. Tracks/501 is obtained, and each child node records detailed information describing a child node record object, such as a child node ID, a child node object name, a child node object type with a byte length of 2 bytes, a child node object storage start block address, a child node storage space byte length, and the like contained in a data area and stored in a small-end format.
S404: according to the B-tree structure information of the file, a node block where the file path/. Traces/501 is located is addressed, information of the file B-tree node block is traversed, whether the current B-tree node block has record information describing the file path/. Traces/501 object is judged, if yes, step S500 is executed, and if not, step S300 is executed.
S500: reading child node record information under each volume path/. Tracks/501: reading child node record information under a volume path/. Tracks/501 one by one, wherein the record information comprises child node ID, child node object timestamp information, child node object name, child node object type, child node object storage starting block address and byte length of a child node object;
s600: judging whether the storage space of the child node of the volume path/trains/501 is distributed, if so, executing the step S800, otherwise, executing the step S700;
the specific steps of step S600 are as follows:
s601: judging the type of a child node object of a volume path/. Tracks/501: reading the record information of the sub-nodes of the volumes per one by one, judging whether each sub-node object type is a folder, if the sub-node object type is 0x0400, indicating that the sub-node object type is a folder, executing a step S602, otherwise, if the sub-node object type is 0x0800, indicating that the sub-node object type is a file, executing a step S603;
s602: acquiring child node contents of the folder nodes: traversing all B-tree node description information of the volume according to the folder node ID, reading child nodes of the folder node, judging whether the child node object type of the folder node is a folder or not, if the child node object type is 0x0400, indicating that the folder is present, executing step S602, otherwise, if the child node object type is 0x0800, indicating that the folder is present, executing step S603;
s603: acquiring node object storage information: according to different node record types, obtaining current node object storage information, wherein the current node object storage information comprises a node ID, a node object name, a node timestamp, a node object storage start block address and a node object byte length;
s604: judging whether the storage space of the node object is allocated: and acquiring the block address information of the node storage space, reading a block allocation information table of an APFS container bitmap manager, acquiring an allocation record identifier of the storage space of the current child node object, if the allocation record identifier is 0, indicating that the storage space is not allocated, executing step S700, otherwise, if the allocation record identifier is 1, the identifier is allocated, and executing step S800.
S700: addressing and extracting data according to the address of the storage block of the child node object;
s800: classifying and extracting data according to the storage condition and the coverage condition of the storage space of the child node of the volume path/. Trashes/501, wherein the storage condition comprises complete distribution and partial distribution, and the coverage condition comprises complete coverage and non-coverage, and the specific steps of the step S800 are as follows:
s801: acquiring current storage object information in a storage space of a child node of a volume path/. Tracks/501: acquiring object description information of current storage data in the allocated storage space, wherein the object description information comprises an object ID of the current storage data, a storage start block address of a child node object and a byte length of the child node object;
s802: judging whether the current storage space is completely distributed, if so, executing a step S803, otherwise, indicating that the current storage space is partially distributed, and executing a step S805;
s803: judging whether the data in the current block is completely covered, if so, executing the step S400, otherwise, executing the step S804;
s804: extracting the uncovered data in the current block, and ending the process;
s805: judging whether the current block in the current storage space is distributed, if so, executing step S806, otherwise, executing step S807;
s806: after repeating steps S803 and S804, step S808 is executed;
s807: extracting data of unallocated blocks in the current storage space according to the storage starting block address of the child node object and the byte length of the child node object;
s808: combining the data of the allocated blocks in the current storage space extracted in step S806 with the data of the unallocated blocks in the current storage space extracted in step S807 to obtain the data in the case that the current storage space is partially allocated, and ending the flow.
The method solves the technical problem that no method for quickly recovering and extracting the deleted files in the APFS exists in the prior art.
It will be understood that the invention is not limited to the examples described above, but that modifications and variations are possible to those skilled in the art in light of the above teachings, and that all such modifications and variations are within the scope of the invention as defined in the appended claims.
Claims (4)
1. A method for rapidly recovering and extracting deleted files in an APFS (advanced persistent file system) is characterized by comprising the following steps:
s100: loading disk data: loading the disk and reading the 0 sector information of the disk, wherein the 0 sector information comprises:
the APFS file system comprises an APFS main super block MSB with a mark of 'NXSB', an ID of an APFS copy-on-write COW, APFS container super block information, APFS container description block information, an APFS bitmap manager block address, an APFS file index block address and an APFS file ID, wherein the APFS main super block MSB is used for describing APFS disk description information; the mark 'NXSB' is used for judging whether the disk data is APFS file system format data or not; the ID of the copy COW is used for determining the sequence of the update data in the APFS container when the APFS container is written; the APFS container superblock information and the APFS container description block information are used for determining the data storage state in the APFS container when the APFS container copies the ID of the COW at different writing times; the APFS bitmap manager is used for storing the distribution use condition of all blocks of an APFS container; the APFS volume index block is used for addressing all volume description information blocks in an APFS container; the APFS volume IDs are used for describing all APFS volume IDs currently contained in the APFS container;
s200: detecting the disk data and judging whether the disk data is data in an APFS file system format, if so, executing a step S300, otherwise, executing a step S100;
s300: parsing the APFS container data: analyzing each volume of the APFS container, each volume index block address and each APFS volume ID;
s400: acquiring child node records under each volume path/. Tracks/501 of the APFS container, judging whether record information describing the volume path/. Tracks/501 object exists, if so, executing step S500, otherwise, executing step S300;
s500: reading child node record information under each volume path/. Tracks/501: reading child node record information under a parcel path/. Tracks/501 one by one, wherein the record information comprises child node ID, child node object timestamp information, child node object name, child node object type, child node object storage starting block address and byte length of a child node object;
s600: judging whether the storage space of the child node of the volume path/. Tracks/501 is distributed, if so, executing the step S800, otherwise, executing the step S700;
s700: addressing and extracting data according to the address of the child node object storage block;
s800: data is extracted by classification according to storage conditions and covering conditions of storage space of a file path/. Tracks/501 child nodes, wherein the storage conditions comprise full allocation and partial allocation, and the covering conditions comprise full covering and uncovering.
2. The method for rapidly recovering and extracting the deleted file in the APFS according to claim 1, wherein the specific steps of the step S400 are as follows:
s401: reading the main superblock MSB of the APFS container: reading sector information No. 0 of the APFS container, wherein the sector information includes the block size of the APFS container, the ID copied when the APFS container is written, the block address description of an APFS container bitmap manager, the block address of an index of an APFS container volume and the ID of the APFS container APFS volume;
s402: addressing a volume checkpoint superblock VCSB according to the APFS container volume index block address: acquiring a file root block according to the file index block address of the main super block MSB, wherein the file root block comprises all APFS file IDs and file block addresses in the APFS container;
s403: reading B-tree structure information of the file volume: traversing all the file information of the file root block, addressing and reading the file check point super block VCSB according to a file block address, wherein the file check point super block VCSB comprises an APFS file ID, the number of allocated blocks of the file, a file B-tree object mapping block address, a file B-tree root node ID and a block address of a file B-tree interval block extentblock;
s404: according to the B-tree structure information of the volume, the node block where the path/. Tracks/501 of the volume is located is addressed, the B-tree node block information of the volume is traversed, whether the current B-tree node block has record information describing the path/. Tracks/501 object of the volume is judged, if yes, step S500 is executed, and if not, step S300 is executed.
3. The method for rapidly recovering and extracting the deleted file in the APFS according to claim 1, wherein the step S600 specifically comprises the following steps:
s601: judging the type of a child node object of a volume path/. Tracks/501: reading the file path/traces/501 child node record information one by one, judging whether each child node object type is a folder, if so, executing step S602, otherwise, executing step S603 if the child node object type is a file;
s602: acquiring child node contents of the folder nodes: traversing all B-tree node description information of the volume according to the folder node ID, reading child nodes of the folder node, judging whether the child node object type of the folder node is a folder, if so, executing step S602, otherwise, executing step S603;
s603: acquiring node object storage information: acquiring current node object storage information including a node ID, a node object name, a node timestamp, a node object storage start block address and a node object byte length according to different node record types;
s604: judging whether the storage space of the node object is allocated: and acquiring the block address information of the node storage space, reading a block allocation information table of an APFS (advanced persistent storage) container bitmap manager, acquiring an allocation record identifier of the storage space of the current child node object, executing step S700 if the allocation record identifier is not allocated, otherwise, executing step S800 if the allocation record identifier is allocated.
4. The method for rapidly recovering and extracting the deleted file in the APFS according to claim 1, wherein the specific steps of the step S800 are as follows:
s801: acquiring current storage object information in a storage space of a child node of a volume path/. Tracks/501: acquiring object description information of current storage data in the allocated storage space, wherein the object description information comprises an object ID of the current storage data, a storage start block address of a child node object and a byte length of the child node object;
s802: judging whether the current storage space is completely allocated, if so, executing step S803, otherwise, indicating that the current storage space is partially allocated, and executing step S805;
s803: judging whether the data in the current block is completely covered, if so, executing the step S400, otherwise, executing the step S804;
s804: extracting the uncovered data in the current block, and ending the process;
s805: judging whether the current block in the current storage space is distributed, if yes, executing step 806, otherwise, executing step 807;
s806: after repeating steps S803 and S804, step S808 is executed;
s807: extracting data of unallocated blocks in the current storage space according to the address of the storage start block of the child node object and the byte length of the child node object;
s808: combining the data of the allocated blocks in the current storage space extracted in step S806 with the data of the unallocated blocks in the current storage space extracted in step S807 to obtain the data in the case that the current storage space is partially allocated, and ending the flow.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910591370.XA CN110309019B (en) | 2019-07-02 | 2019-07-02 | Method for rapidly recovering and extracting deleted files in APFS (advanced persistent file system) |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910591370.XA CN110309019B (en) | 2019-07-02 | 2019-07-02 | Method for rapidly recovering and extracting deleted files in APFS (advanced persistent file system) |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110309019A CN110309019A (en) | 2019-10-08 |
| CN110309019B true CN110309019B (en) | 2022-11-04 |
Family
ID=68078332
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910591370.XA Active CN110309019B (en) | 2019-07-02 | 2019-07-02 | Method for rapidly recovering and extracting deleted files in APFS (advanced persistent file system) |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110309019B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111597075B (en) * | 2020-05-11 | 2023-04-07 | 成都艾勃科技有限公司 | Method for recovering data from data storage device encrypted by hardware |
| CN111737057A (en) * | 2020-06-24 | 2020-10-02 | 深圳软牛科技有限公司 | APFS file system data recovery method and device and electronic equipment |
| CN112463736B (en) * | 2020-12-11 | 2022-05-20 | 厦门市美亚柏科信息股份有限公司 | Recovery method and system for APFS file |
| CN112650718A (en) * | 2020-12-30 | 2021-04-13 | 四川效率源信息安全技术股份有限公司 | Method for analyzing and extracting BTRFS file system data based on copy-on-write |
| CN113076221B (en) * | 2021-03-30 | 2023-05-02 | 四川效率源信息安全技术股份有限公司 | Data recovery method for MongoDB-MMAPv1 engine |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108108394A (en) * | 2017-11-28 | 2018-06-01 | 厦门市美亚柏科信息股份有限公司 | The compressed file restoration methods and storage medium of APFS file system |
| CN109582500A (en) * | 2018-11-26 | 2019-04-05 | 万兴科技股份有限公司 | Data reconstruction method, device, computer equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080263103A1 (en) * | 2007-03-02 | 2008-10-23 | Mcgregor Lucas | Digital asset management system (DAMS) |
-
2019
- 2019-07-02 CN CN201910591370.XA patent/CN110309019B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108108394A (en) * | 2017-11-28 | 2018-06-01 | 厦门市美亚柏科信息股份有限公司 | The compressed file restoration methods and storage medium of APFS file system |
| CN109582500A (en) * | 2018-11-26 | 2019-04-05 | 万兴科技股份有限公司 | Data reconstruction method, device, computer equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110309019A (en) | 2019-10-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110309019B (en) | Method for rapidly recovering and extracting deleted files in APFS (advanced persistent file system) | |
| US9836362B2 (en) | Cyclic commit transaction protocol | |
| CN111581163B (en) | Data traceless deletion method and system based on NTFS (New technology File System) | |
| CN110297729B (en) | Method for recovering damaged data and deleted data in APFS (advanced persistent file system) based on interval block | |
| WO2020103493A1 (en) | Method and system for recovering deleted file based on fat32 file system | |
| CN110515543B (en) | Object bucket-based snapshot method, device and system | |
| US11243850B2 (en) | Image recovery from volume image files | |
| CN104199888A (en) | Data recovery method and device for resilient file system | |
| CN112463724A (en) | Data processing method and system for lightweight file system | |
| KR101593184B1 (en) | Method and apparatus for recovering partition based on file system metadata | |
| CN106709014B (en) | File system conversion method and device | |
| CN114625696A (en) | File recovery method and device, electronic equipment and storage medium | |
| US8190655B2 (en) | Method for reliable and efficient filesystem metadata conversion | |
| US20140244699A1 (en) | Apparatus and Methods for Selective Location and Duplication of Relevant Data | |
| CN110297781B (en) | Method for recovering deleted data in APFS (advanced File System) based on copy-on-write | |
| Vandermeer et al. | Forensic analysis of the exfat artefacts | |
| CN105760244A (en) | exFAT formatting recovery method and device based on hypothesis and verification | |
| CN113821476B (en) | Data processing method and device | |
| EP2075796A1 (en) | Methods and devices for managing reading, writing and truncating a file system | |
| US20180024759A1 (en) | Indirection-Based Storage System Backups | |
| CN110781160B (en) | Data recovery method based on VMware virtualization file system damage | |
| CN107818136B (en) | Method and device for recycling garbage object data | |
| CN114556283A (en) | Method and device for data writing, consistency checking and reading | |
| CN112380174B (en) | XFS file system analysis method containing deleted files, terminal device and storage medium | |
| CN103700388A (en) | File recording apparatus, file system management method, file recovery method, and changer drive |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |