CN102289526B - HFS+file system data recovery method and device - Google Patents
HFS+file system data recovery method and device Download PDFInfo
- Publication number
- CN102289526B CN102289526B CN 201110293363 CN201110293363A CN102289526B CN 102289526 B CN102289526 B CN 102289526B CN 201110293363 CN201110293363 CN 201110293363 CN 201110293363 A CN201110293363 A CN 201110293363A CN 102289526 B CN102289526 B CN 102289526B
- Authority
- CN
- China
- Prior art keywords
- node
- head
- file
- volume
- module
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to an HFS+file system data recovery method and device. The method comprises the following steps: A, scanning a file in the storage medium by taking a sector as a unit; B, finding the volume header from the scanned file; if the volume header is found, executing a step C; and otherwise, executing the step A, and scanning the next sector; C, finding the head node from a directory file corresponding to the found volume header; if the head node is found, executing a step F; and otherwise, executing a step D; D, judging whether the found volume header is a backup volume header; if the found volume header is a backup volume header, executing a step E; and otherwise, executing the step A, and scanning the next sector; E, positioning the head node; if the head node is positioned, executing a step F; and otherwise, executing the step A, and scanning the next sector; and F, traversing a B-tree included in all positioned head nodes, and recovering the file data. The method can recover the files in the HFS+formatted file system ever existing on the storage medium.
Description
Technical field
The present invention relates to the Computer Applied Technology field, more particularly, relate to a kind of HFS+ file system data restoration methods and device.
Background technology
Hierarchical file system (Hierarchical File System, HFS) be the employed a kind of file system of Mac operating system of Macintosh, Mac operating system is used the HFS file system in early days, HFS+ is the upgraded version of HFS, done some important improvement on the basis of HFS, the institutional framework of HFS+ volume as shown in Figure 1.
Comprising: reserve area (Reservide), this area data are complete 0; Volume head (Volume Header), each HFS+ volume all must have one to roll up head, rolls up head memory and is storing up the various information relevant with volume, as the date and time that volume is set up, rolls up interior quantity of documents etc., also has the memory location of other important structure of volume; Duplicate volume head (Alternate Volume Header), the backup of volume head; Allocate file (Alternate File), being used for describing a distribution is the occupied or free time soon; Territory spill file (Extents Overflow File), more than the fileinfo in 8 territories, the part that exceeds is kept at here; Catalogue file (Catalog File), be used for describing file and directory hierarchy in the volume, it is storing the important information of All Files and catalogue in the volume, and B-tree (B-tree) structure of catalogue file can be fast and be effectively sought file destination in a lot of big catalogue of level; Property file (Attributes File) is used for preserving the additional information of file or catalogue; Startup file (Startup File).
Macintosh comes data are managed with the B-tree structure, as index, just can find the file of our needs with it by this index.B-tree is a kind of multichannel search tree, and it must satisfy: 1, any non-leaf node of definition has only M son at most, and M＞2; 2, son's number of root node is [2, M]; 3, son's number of the non-leaf node except that root node is [M/2, M]; 4, each node is deposited M/2-1 (getting whole) and M-1 key word (at least 2 key words) at least at the most; 5, the key word of non-leaf node number=sensing son's pointer number-1; 6, the key word of non-leaf node: K[1], K[2] ... K[M-1]; And K[i]＜K[i+1]; 7, the pointer of non-leaf node: P[1], P[2] ..., P[M]; P[1 wherein] point to key word less than K[1] subtree, P[M] point to key word greater than K[M-1] subtree, other P[i] point to the subtree that key word belongs to (K[i-1], K[i]); 8, all leaf nodes are positioned at same one deck.
The B-tree file is divided in each node of fixed size " node (Node) " and all comprises corresponding archives item.Each archives Xiang Youyi key word (key) and some data are formed.In the HFS+ file, have 4 kinds of nodes: head node, node of graph, index node and leaf node.Wherein, index node and leaf node are as shown in Figure 2, index node is used for other index node of index, perhaps index leaf node, leaf node is used to search data, what the content format of each entry of node is, see that this node is child node or leaf node, and belongs to catalogue file or territory spill file or the like.
Head node in the B-tree file is first node of B-tree, every B-tree has a unique head node, structure as shown in Figure 3, it comprises the information that how to find other nodes among the B-tree, comprising: node is described (Node Descriptor), B-tree head record (B-tree Header Record), user data record (User Data Record), B-tree map record (B-tree Map Record), be offset to clearance spaces (Offset to Free Space), be offset to record 2 (Offset to Record 2), be offset to record 1 (Offset to Record 1), be offset to record 0 (Offset to Record 0).
In the existing Macintosh system, when being HFS+ file partition quilt subregion again originally, or by reformatting, perhaps partition table damages and can't discern subregion, what perhaps can't discern when being the file system of form, adopt present various data recover softwares all can't recover before file in the HFS+ file system, therefore can cause the user to lose vital document information.
Summary of the invention
The technical problem to be solved in the present invention is, at the above-mentioned defective of prior art, provides a kind of HFS+ file system data restoration methods and device, adopts this method and installs the HFS+ formatted file that can recover in the storage medium.
The technical solution adopted for the present invention to solve the technical problems is:
Construct a kind of HFS+ file system data restoration methods, wherein, may further comprise the steps:
A, be that unit scans the file in the storage medium with the sector;
B, search the volume head from scanned document, if find described volume head, execution in step C, otherwise execution in step A scan next sector;
C, according to each field in the node descriptor of head node and each field in the first gear case, from a described volume pairing catalogue file that is found, search head node, if find head node, execution in step F then, otherwise execution in step D;
D, judge whether described volume head is the duplicate volume head, if the duplicate volume head, execution in step E, otherwise execution in step A scan next sector;
E, release the position of described volume head according to the inverse position of described duplicate volume head, again according to each field positioning head node of a described volume position and duplicate volume head, if navigate to head node, execution in step F then, otherwise execution in step A scans next sector;
F, travel through the B-tree that is comprised in all head nodes that navigate to, obtain wherein file and directory information, the recovery file data.
HFS+ file system data restoration methods of the present invention, wherein, among the described step B, when searching described volume, judge the volume head signature of file, 16 systems are that 0x482b and version equal 4 if the volume head of file is signed, and perhaps the volume head of file 16 systems of signing are that 0x4858 and version equal 5, then are described volume head.
HFS+ file system data restoration methods of the present invention, wherein, any one that described step B is further comprising the steps of or a plurality of side by side:
The Volume Properties of step B1, judgement file if described Volume Properties equals 0x80002000 or equals 0x80000000, then is described volume head, and execution in step C, otherwise execution in step A scan next sector;
The last loading version of step B2, judgement file if described last loading version 16 systems are 0x4846534a or 0x46534b21, then is described volume head, and execution in step C, otherwise execution in step A scan next sector;
Step B3, judge the date created of file, if described date created be not equal to 0 and revise the date be not equal to 0 and Check Date be not equal to 0, then be described volume head, execution in step C, otherwise execution in step A scan next sector;
The allocation block size of step B4, judgement file, if described allocation block size equals 0x1000 and resource fork default tile group size equals 0x10000 and data fork default tile group size equals 0x10000, then is described volume head, execution in step C, otherwise execution in step A scans next sector;
Step B5, judge allocate file, territory spill file, catalogue file, property file and startup file in the file, equal total block data if the logic size of described allocate file, territory spill file, catalogue file, property file and startup file equals the summation that the allocation block size multiply by the allocation block number of total block data and field descritor.
HFS+ file system data restoration methods of the present invention, wherein, among the described step C, search described head node method and be:
Judge each field of the first gear case of each field in the node descriptor of described head node and described head node, if the last node number in the node descriptor of described head node equals 0, node type equals 1, height of node equals 0, the archives number equal 3 and reserved field equal 0, and the root node of the first gear case of described head node number greater than 0 and less than the node sum, do not use the node number less than node sum, first leaf segment period less than node sum, last leaf segment period and less than the node sum, then think described head node.
HFS+ file system data restoration methods of the present invention, wherein, among the described step C, the first gear case of described head node also needs to satisfy following any one or a plurality of condition:
Node size is between 512 and 32768;
Node type is 0;
The tree maximum height is greater than 0 and less than 16.
HFS+ file system data restoration methods of the present invention, wherein, described step F comprises step:
F1, search leaf node, each node that the B-tree is read in skew that begins from described head node, judge each field of the node descriptor of the node of reading, if the node type of the node descriptor of the node of reading equals-1, height of node less than 16 and reserved field equal 0, then be judged as described leaf node, execution in step F2;
F2, recovery file data are resolved the archive information that writes down in the described leaf node, decomposite directory file item and archive files item, according to the positional information and the size information recovery file of the record of the data fork in the described archive files item.
HFS+ file system data restoration methods of the present invention, wherein, in the described step F 1, search described leaf node and also need satisfy two conditions of following any one conditioned disjunction:
The next node of the node descriptor of the node of reading is less than or equal to the node sum of the first gear case of head node;
A last node number of the node of reading is less than or equal to the node sum of the first gear case of head node.
The present invention also provides a kind of HFS+ file system data recovery device, comprises that sector scanning module, volume head are searched module, head node is searched module, duplicate volume head judge module, head node locating module and file and recovered module: wherein,
Described sector scanning module is used for the sector that to be unit scan the file of storage medium;
Described volume head is searched module, is used for searching the volume head from scanned document, if find described volume head, then triggers described head node and searches module, searches head node, otherwise triggers described sector scanning module, continues next sector of scanning;
Described head node is searched module, be used for according to each field of the node descriptor of head node and each field in the first gear case, from a described volume pairing catalogue file that is found, search head node, if navigate to described head node, then trigger described file and recover module, the recovery file data, otherwise trigger described duplicate volume head judge module, judge whether the volume head is the duplicate volume head;
Described duplicate volume head judge module is used to judge whether described volume head is the duplicate volume head, if find described duplicate volume head, then triggers described head node locating module, the positioning head node, otherwise trigger described sector scanning module, continue next sector of scanning;
Described head node locating module, be used for releasing the position of described volume head according to the inverse position of described duplicate volume head, again according to each field positioning head node of a described volume position and duplicate volume head, if navigate to described head node, then trigger described file and recover module, the recovery file data, otherwise trigger described sector scanning module, continue next sector of scanning;
Described file recovers module, is used for traveling through all B-that head node comprised that navigates to trees, obtains wherein file and directory information, the recovery file data.
HFS+ file system data recovery device of the present invention, wherein, described volume head is searched module and is comprised:
Volume head signature judging unit, be used for when searching described volume, judge the volume head signature of file, 16 systems are that 0x482b and version equal 4 if the volume head of described file is signed, perhaps the volume head of described file 16 systems of signing are that 0x4858 and version equal 5, then are described volume head.
HFS+ file system data recovery device of the present invention, wherein, described head node is searched module and is comprised:
The head node judging unit, be used for judging each field of the first gear case of each field of node descriptor of described head node and described head node, if the last node number in the node descriptor of described head node equals 0, node type equals 1, height of node equals 0, the archives number equal 3 and reserved field equal 0, and the root node of the first gear case of described head node is number greater than 0 and less than the node sum, do not use the node number less than the node sum, first leaf segment period is less than the node sum, last leaf segment period and less than the node sum is then thought described head node.
Beneficial effect of the present invention is: by the file in the scan storage media, and find the volume head, find head node by the volume head again, travel through the B-tree that is comprised in all catalogue file head nodes that navigate to then, obtain wherein file and directory information, the recovery file data, after adopting such data reset mode, so long as once there was the file system of HFS+ form on the storage medium, deleted HFS+ formatted file just HFS+ formatted file wherein might be recovered out, even also might be resumed out.
Description of drawings
The invention will be further described below in conjunction with drawings and Examples, in the accompanying drawing:
Fig. 1 is the institutional framework synoptic diagram of HFS+ volume of the prior art;
Fig. 2 is index node and the leaf node synoptic diagram in the B-tree file of the prior art;
Fig. 3 is the head node synoptic diagram in the B-tree file of the prior art;
Fig. 4 is the HFS+ file system data restoration methods flow process of preferred embodiment of the present invention;
Fig. 5 is a step S130 process flow diagram in the HFS+ file system data restoration methods of preferred embodiment of the present invention;
Fig. 6 is the HFS+ file system data recovery device theory diagram of preferred embodiment of the present invention;
Fig. 7 is that the volume head is searched the module principle block diagram in the HFS+ file system data recovery device of preferred embodiment of the present invention.
Embodiment
The HFS+ file system data restoration methods flow process of preferred embodiment of the present invention as shown in Figure 4, this method S100 starts from step S110.
In step S120, be that unit scans the file in the storage medium with the sector.In the file system of HFS+ form, the position of volume head on storage medium is unit with the sector, and preceding two sectors of volume head are reserve area, begin file is scanned from second sector of storage medium so be unit with the sector, with the volume head of locating file.
In step S130, from scanned document, search the volume head, if find the volume head, execution in step S140, otherwise execution in step S120 scan next sector.Owing to include the various information relevant in the volume head of file with volume, as roll up the date and time of foundation, quantity of documents in the volume etc., the memory location that also has other important structure of volume, therefore find after the volume head, can come the head node of locating file according to the information in the volume head, the B-tree information in then can head node indexes, and both can navigate to by this index needs the file that recovers.
Preferably, in above-mentioned steps S130, during the volume of locating file, the main volume head signature of judging file, if the volume head of file signature (signature) equals " H+ ", 16 systems are that 0x482b and version equal 4, and perhaps the volume head of file 16 systems of signing are that 0x4858 and version equal 5, then are the volume head.
More preferably, as shown in Figure 5, step S130 is except comprising step S131, judge promptly whether volume head signature 16 systems are 0x482b, and version equals 4, perhaps whether the volume head of file 16 systems of signing are 0x4858, and version equals outside 5, also further comprise step S132, S133, S134, S135, among the S136 one step or multistep, further judge promptly whether among file following every one or more satisfy condition, comprise: Volume Properties, load version at last, date created, the allocation block size is perhaps judged allocate file in the volume head simultaneously, the territory spill file, catalogue file, the logic size of property file and startup file.
As follows to above-mentioned every Rule of judgment:
In step S132, judge the Volume Properties of file, if Volume Properties (attributes) equals 0x80002000 or equals 0x80000000, then be the volume head, otherwise give up;
In step S133, judge the last loading version of file, equal " HFSJ " (16 systems are 0x4846534a) if load version (last Mounted Version) at last, perhaps equal " FSK! " (16 systems are 0x46534b21), then be the volume head, otherwise give up;
In step S134, judge the date created of file, if date created (create Date) be not equal to 0, revise the date (modify Date) be not equal to 0 and Check Date (check Data) be not equal to 0, then be the volume head, otherwise give up;
In step S135, judge the allocation block size of file, if allocation block size (block Size) equals 0x1000 and resource fork default tile group size (rsrc Clump Size) equals 0x10000 and data fork default tile group size (data ClumpSize) equals 0x10000, then be the volume head, otherwise give up;
In step S136, judge the allocate file in the volume head, the territory spill file, catalogue file, property file and startup file, because what these files all used is fork data structure (HFS Plus Fork Data structure), if the allocate file in the volume head, the territory spill file, catalogue file, property file and startup file all satisfy logic size (logical Size) and equal the summation that the allocation block size multiply by the allocation block number (block Count) of total block data (total Blocks) and field descritor (HFS Plus Extent Descriptor) and will equal total block data (total Blocks).
Two steps in comprising step S132, S133, S134, S135, S136, the execution of each step can be carried out simultaneously with a volume signature process of judging file when above, and not free each other sequencing can be self-defined according to technician's demand.Certainly, many more to the constraint condition of volume head, resulting volume head is also accurate more, when judge simultaneously above-mentioned all, all that then may obtain in the file are rolled up heads.
Therefore, in step S137, can be set to then be defined as rolling up head, execution in step S140 when a judged result being arranged when being among S132, S133, S134, S135, the S136; Also step S137 can be set at,, just be defined as rolling up head, execution in step S140, otherwise execution in step S120 when all judged results among step S132, S133, S134, S135, the S136 are when being.Or other conditions of setting as required, and should not be limited to the step shown in Fig. 5.
In step S140, according to each field in the node descriptor of head node and each field in the first gear case, from a volume pairing catalogue file that is found, search head node, if find head node, execution in step S170 then, otherwise execution in step S150.
Particularly, each field of the node descriptor in the head node (BT Node Descriptor) must satisfy following condition simultaneously:
(1-1), a last node number (b Link) equals 0;
(1-2), node type (kind) equals 1;
(1-3), height of node (height) equals 0;
(1-4), archives number (num Records) equals 3;
(1-5), reserved field (Reserved) equals 0.
Each field of the first gear case of head node (BT Header Rec) must satisfy following condition simultaneously:
(2-1), root node number (root Node) is greater than 0 and less than node sum (total Nodes);
(2-2), do not use node number (free Nodes) less than node sum (total Nodes);
(2-3), first leaf segment period (first Leaf Node) is less than node sum (total Nodes);
(2-4), last leaf segment period (last Leaf Node) is less than node sum (total Nodes).
When each field in the node descriptor of head node and each field in the first gear case satisfy above-mentioned condition, then think head node, execution in step S170, otherwise execution in step S150.
Further, the first gear case of head node also needs to meet the following conditions:
(2-5), node size (node Size), must be 2 integral number power with byte representation, between 512 and 32768;
(2-6), node type (btree Type) is 0;
(2-7), tree maximum height (tree Depth) is greater than 0 and less than 16.
Can set as required: each field in the node descriptor of head node satisfy condition (1-1), (1-2), (1-3), (1-4), (1-5), and when each field in the first gear case satisfies (2-1), (2-2), (2-3), (2-4), (2-5), (2-6), (2-7), just then think head node, execution in step S170, otherwise execution in step S150.Can guarantee that like this head node judgement is more accurate, the integrality of restore data to guarantee.
In step S150, judge whether the volume head of being searched is the duplicate volume head, if the duplicate volume head, execution in step S160, otherwise execution in step S120 scan next sector.Wherein, judge whether to the method for duplicate volume head to be, judge the last loading version of the volume head of being searched, if the last loading version of volume head equals " 10.0 ", 16 systems are 0x31302e30, then are the duplicate volume head.
In step S160, release the position of volume head according to the inverse position of duplicate volume head, again according to each field positioning head node of a volume position and duplicate volume head, if navigate to head node, execution in step S170 then, otherwise execution in step S120 scans next sector.The duplicate volume head is the copy of volume head, when total size of volume when just in time being the integral multiple of allocation block size (block Size), the allocation block sum (total Blocks) that total size of volume equals to roll up head/duplicate volume head multiply by the allocation block size (block Size) of volume head/duplicate volume head.And when volume size when not being the integral multiple of allocation block size (block Size), then the piece number of allocation block sum (total Blocks) record does not just comprise the space of the not enough allocation block that afterbody has more.So can be from the position of duplicate volume head backstepping volume head, but exist allocation block size (block Size) to remove the 512 (sizes of a sector, because the allocation block size must be the integral multiple of sector-size, the volume size also must be the integral multiple of sector-size) deviation of individual sector.
Then earlier the size of hypothesis volume is the integral multiple of allocation block, and the make the test position of head of backstepping according to each field of a volume position and duplicate volume head, navigates to the head node of catalogue file, finds that this head node location is correct, proves that then the volume head of institute's backstepping is correct.If incorrect, then try to deduct a sector with the position of former backstepping at every turn, locate the head node of catalogue file again, the head node up to the location is correct, perhaps subtracts allocation block size (block Size) and removes the number of times of 512 sectors.Find paired volume head and duplicate volume head just can confirm the volume head, and azygous volume head and duplicate volume head may be to be damaged or non-volume head.
In step S170, travel through the B-tree that is comprised in all catalogue file head nodes that navigate to, obtain wherein file and directory information, the recovery file data.Head node begin to be offset be exactly B-tree begin the skew, learn each size of node from the node size (node Size) of head node, node sum (total Nodes) is learnt the sum of node, then the skew that begins from head node reads out each node, node may be that index node also may be leaf node or unique head node, and these three kinds of nodes all have a node descriptor (BT Node Descriptor) structure.
Specifically comprise: a, search leaf node, each node that the B-tree is read in skew that begins from head node, judge each field of the node descriptor of the node of reading, if the node type of the node descriptor of the node of reading equals-1, height of node less than 16 and reserved field equal 0, then be judged as leaf node, execution in step b;
B, recovery file data, resolve the archive information that writes down in the leaf node, decomposite directory file item (HFS Plus Catalog Folder) and archive files item (HFS Plus Catalog File), according to the positional information and the size information of the data fork in the archive files item (data Fork) record, recovery file.
Preferably, among the above-mentioned steps a, search leaf node also need satisfy condition for: the next node of the node descriptor of the node of reading is less than or equal to the node sum of the first gear case of head node.Perhaps further comprise a last node number of judging the node of reading, if a last node number of the node of reading is less than or equal to the node sum of the first gear case of head node.
Said method S100 ends at step S180.
In another embodiment of the present invention, a kind of HFS+ file system data recovery device also is provided, as shown in Figure 6, comprising: sector scanning module 10, volume head are searched module 20, head node is searched module 30, duplicate volume head judge module 40, head node locating module 50 and file and recovered module 60.Wherein, sector scanning module 10, be used for the sector that to be unit scan the file of storage medium, in the file system of HFS+ form, the position of volume head on storage medium is unit with the sector, and preceding two sectors of volume head are reserve area, begin file is scanned from second sector of storage medium so be unit with the sector, with the volume head of locating file.
The volume head is searched module 20, is used for searching the volume head from scanned document, if find the volume head, then the trigger head node is searched module 30, searches head node, otherwise triggers sector scanning module 10, continues next sector of scanning.Owing to include the various information relevant in the volume head of file with volume, as roll up the date and time of foundation, quantity of documents in the volume etc., the memory location that also has other important structure of volume, therefore find after the volume head, can come the head node of locating file according to the information in the volume head, the B-tree information in then can head node indexes, and both can navigate to by this index needs the file that recovers.
Head node is searched module 30, is used for searching head node according to each field of the node descriptor of head node and each field in the first gear case from a volume pairing catalogue file that is found.If navigate to head node, then trigger file and recover module 60, the recovery file data, otherwise trigger duplicate volume head judge module 40, judge whether the volume head is the duplicate volume head.
Duplicate volume head judge module 40 is used for judging whether the volume head is the duplicate volume head.Wherein, judge whether to the method for duplicate volume head to be, judge the last loading version of the volume head of being searched, if the last loading version of volume head equals " 10.0 ", 16 systems are 0x31302e30, then are the duplicate volume head.If find the duplicate volume head, trigger head node locating module 50 then, the positioning head node, otherwise trigger sector scanning module 10, continue next sector of scanning.
Head node locating module 50 is used for releasing the position of rolling up head according to the inverse position of duplicate volume head, again according to each field positioning head node of rolling up a position and duplicate volume head.If navigate to head node, then trigger file and recover module 60, the recovery file data, otherwise trigger sector scanning module 10, continue next sector of scanning.Because the duplicate volume head is the copy of volume head, when total size of volume when just in time being the integral multiple of allocation block size (block S1ze), the allocation block sum (total Blocks) that total size of volume equals to roll up head/duplicate volume head multiply by the allocation block size (block Size) of volume head/duplicate volume head.And when volume size when not being the integral multiple of allocation block size (block Size), then the piece number of allocation block sum (total Blocks) record does not just comprise the space of the not enough allocation block that afterbody has more.So can be from the position of duplicate volume head backstepping volume head, but exist allocation block size (block Size) to remove the 512 (sizes of a sector, because the allocation block size must be the integral multiple of sector-size, the volume size also must be the integral multiple of sector-size) deviation of individual sector.
File recovers module 60, is used for traveling through all B-that head node comprised that navigates to trees, obtains wherein file and directory information, the recovery file data.Head node begin to be offset be exactly B-tree begin the skew, learn each size of node from the node size (node Size) of head node, node sum (total Nodes) is learnt the sum of node, then the skew that begins from head node reads out each node, node may be that index node also may be leaf node or unique head node, and these three kinds of nodes all have a node descriptor (BT Node Descriptor) structure.
Specifically comprise: a, search leaf node, each node that the B-tree is read in skew that begins from head node, judge each field of the node descriptor of the node of reading, if the node type of the node descriptor of the node of reading equals-1, height of node less than 16 and reserved field equal 0, then be judged as leaf node, execution in step b;
B, recovery file data, resolve the archive information that writes down in the leaf node, decomposite directory file item (HFSPlus Catalog Folder) and archive files item (HFS Plus Catalog File), according to the positional information and the size information of the data fork in the archive files item (data Fork) record, recovery file.
Preferably, among the above-mentioned steps a, search leaf node also need satisfy condition for: the next node of the node descriptor of the node of reading is less than or equal to the node sum of the first gear case of head node.Perhaps further comprise a last node number of judging the node of reading, if a last node number of the node of reading is less than or equal to the node sum of the first gear case of head node.
In a further embodiment, as shown in Figure 7, the volume head of above-mentioned HFS+ file system data recovery device is searched module 20 and is comprised: volume head signature judging unit 21, be used for search the volume the time, judge the volume head signature of file, 16 systems are that 0x482b and version equal 4 if the volume head of file is signed, and perhaps the volume head of file 16 systems of signing are that 0x4858 and version equal 5, then are the volume head.
In embodiment further, as shown in Figure 7, above-mentioned volume head is searched module 20 and is also comprised: Volume Properties judging unit 22, at last load in version judging unit 23, date created judging unit 24, allocation block size judging unit 25 and the file logic size judging unit 26 or a plurality of.Be respectively applied for and further judge whether the following every of file satisfies condition, comprise: Volume Properties, load version, date created, allocation block size at last, perhaps judge the logic size of allocate file, territory spill file, catalogue file, property file and startup file in the volume head simultaneously.
Wherein, Volume Properties judging unit 22 is used to judge the Volume Properties of file, if Volume Properties (attributes) equals 0x80002000 or equals 0x80000000, then is the volume head, otherwise gives up; Load version judging unit 23 at last, be used to judge the last loading version of file, equal " HFSJ " (16 systems are 0x4846534a) if load version (last Mounted Version) at last, perhaps equal " FSK! " (16 systems are 0x46534b21), then be the volume head, otherwise give up; Date created judging unit 24 is used to judge the date created of file, if date created (create Date) be not equal to 0, revise the date (modify Date) be not equal to 0 and Check Date (check Data) be not equal to 0, then be the volume head, otherwise give up; Allocation block size judging unit 25, be used to judge the allocation block size of file, if allocation block size (block Size) equals 0x1000 and resource fork default tile group size (rsrc Clump Size) equals 0x10000 and data fork default tile group size (data ClumpSize) equals 0x10000, then be the volume head, otherwise give up; File logic size judging unit 26, be used for judging the allocate file of volume head, the territory spill file, catalogue file, property file and startup file, because what these files all used is fork data structure (HFS Plus Fork Data structure), if the allocate file in the volume head, the territory spill file, catalogue file, property file and startup file all satisfy logic size (logical Size) and equal the summation that the allocation block size multiply by the allocation block number (block Count) of total block data (total Blocks) and field descritor (HFS Plus Extent Descriptor) and will equal total block data (total Blocks).
Searching module 20 when volume head comprises Volume Properties judging unit 22, loads in version judging unit 23, date created judging unit 24, allocation block size judging unit 25 and the file logic size judging unit 26 two when above at last, the execution of each unit can be synchronous with volume head signature judging unit, not free each other sequencing can be self-defined according to technician's demand.Certainly, many more to the constraint condition of volume head, resulting volume head is also accurate more, when judge simultaneously above-mentioned all, all that then may obtain in the file are rolled up heads.
In a further embodiment, the head node of above-mentioned HFS+ file system data recovery device is searched module 30 and is comprised: the head node judging unit, be used for judging each field of the first gear case of each field of node descriptor of head node and head node, if the last node number in the node descriptor of head node equals 0, node type equals 1, height of node equals 0, the archives number equal 3 and reserved field equal 0; And the root node of the first gear case of head node number greater than 0 and less than the node sum, do not use the node number less than node sum, first leaf segment period less than node sum, last leaf segment period and less than the node sum, then think head node.
Whether in embodiment further, above-mentioned head node judging unit also is further used for decision node size (node Size), must be 2 integral number power with byte representation, between 512 and 32768; Whether node type (btree Type) is 0; Whether tree maximum height (tree Depth) is greater than 0 and less than 16.It is more accurate to judge with the assurance head node, guarantees the integrality of institute's restore data.HFS+ file system data restoration methods of the present invention and device, by the file in the scan storage media, and find the volume head, find head node by the volume head again, travel through the B-tree that is comprised in all catalogue file head nodes that navigate to then, obtain wherein file and directory information, the recovery file data, after adopting such data reset mode, so long as once there was the file system of HFS+ form on the storage medium, deleted HFS+ formatted file just HFS+ formatted file wherein might be recovered out, even also might be resumed out.Solved that to cause for some reason in the prior art discerning be the file system of what form, perhaps maloperation is formatted as reasons such as alternative document system, and causing is the storage medium of HFS+ file system originally, the problem that can't be identified.
Should be understood that, for those of ordinary skills, can be improved according to the above description or conversion, and all these improvement and conversion all should belong to the protection domain of claims of the present invention.
Claims (7)
1. a HFS+ file system data restoration methods is characterized in that, may further comprise the steps:
A, be that unit scans the file in the storage medium with the sector;
B, search the volume head from scanned document, if find described volume head, execution in step C, otherwise execution in step A scan next sector;
C, according to each field in the node descriptor of head node and each field in the first gear case, from a described volume pairing catalogue file that is found, search head node, if find head node, execution in step F then, otherwise execution in step D;
D, judge whether described volume head is the duplicate volume head, if the duplicate volume head, execution in step E, otherwise execution in step A scan next sector;
E, release the position of described volume head according to the inverse position of described duplicate volume head, again according to each field positioning head node of a described volume position and duplicate volume head, if navigate to head node, execution in step F then, otherwise execution in step A scans next sector;
F, travel through the B-tree that is comprised in all head nodes that navigate to, obtain wherein file and directory information, the recovery file data;
Among the described step C, search described head node method and be:
Judge each field of the first gear case of each field in the node descriptor of described head node and described head node, if the last node number in the node descriptor of described head node equals 0, node type equals 1, height of node equals 0, the archives number equal 3 and reserved field equal 0;
And the root node of the first gear case of described head node number greater than 0 and less than the node sum, do not use the node number less than node sum, first leaf segment period less than node sum, last leaf segment period and less than the node sum, then think described head node;
Described step F comprises step:
F1, search leaf node, each node that the B tree is read in skew that begins from described head node, judge each field of the node descriptor of the node of reading, if the node type of the node descriptor of the node of reading equals-1, height of node less than 16 and reserved field equal 0, then be judged as described leaf node, execution in step F2; F2, recovery file data are resolved the archive information that writes down in the described leaf node, decomposite directory file item and archive files item, according to the positional information and the size information recovery file of the record of the data fork in the described archive files item.
2. HFS+ file system data restoration methods according to claim 1, it is characterized in that, among the described step B, when searching described volume, judge the volume head signature of file, 16 systems are that 0x482b and version equal 4 if the volume head of described file is signed, and perhaps the volume head of described file 16 systems of signing are that 0x4858 and version equal 5, then are described volume head.
3. HFS+ file system data restoration methods according to claim 2 is characterized in that, any one that described step B is further comprising the steps of or a plurality of side by side:
The Volume Properties of step B1, judgement file if described Volume Properties equals 0x80002000 or equals 0x80000000, then is described volume head, and execution in step C, otherwise execution in step A scan next sector;
The last loading version of step B2, judgement file if described last loading version 16 systems are 0x4846534a or 0x46534b21, then is described volume head, and execution in step C, otherwise execution in step A scan next sector; Step B3, judge the date created of file, if described date created be not equal to 0 and revise the date be not equal to 0 and Check Date be not equal to 0, then be described volume head, execution in step C, otherwise execution in step A scan next sector;
The allocation block size of step B4, judgement file, if described allocation block size equals 0x1000 and resource fork default tile group size equals 0x10000 and data fork default tile group size equals 0x10000, then is described volume head, execution in step C, otherwise execution in step A scans next sector;
Allocate file, territory spill file, catalogue file, property file and startup file in step B5, the judgement file, if the logic size of described allocate file, territory spill file, catalogue file, property file and startup file equals the summation that the allocation block size multiply by the allocation block number of total block data and field descritor and equals total block data, then is described volume head.
4. HFS+ file system data restoration methods according to claim 1 is characterized in that, among the described step C, the first gear case of described head node also needs to satisfy following any one or a plurality of condition:
Node size is between 512 and 32768;
Node type is 0;
The tree maximum height is greater than 0 and less than 16.
5. HFS+ file system data restoration methods according to claim 1 is characterized in that, in the described step F 1, searches described leaf node and also need satisfy two conditions of following any one conditioned disjunction:
The next node of the node descriptor of the node of reading is less than or equal to the node sum of the first gear case of head node; A last node number of the node of reading is less than or equal to the node sum of the first gear case of head node.
6. a HFS+ file system data recovery device is characterized in that, comprises that sector scanning module, volume head are searched module, head node is searched module, duplicate volume head judge module, head node locating module and file and recovered module: wherein,
Described sector scanning module is used for the sector that to be unit scan the file of storage medium;
Described volume head is searched module, is used for searching the volume head from scanned document, if find described volume head, then triggers described head node and searches module, searches head node, otherwise triggers described sector scanning module, continues next sector of scanning;
Described head node is searched module, be used for according to each field of the node descriptor of head node and each field in the first gear case, from a described volume pairing catalogue file that is found, search head node, if navigate to described head node, then trigger described file and recover module, the recovery file data, otherwise trigger described duplicate volume head judge module, judge whether the volume head is the duplicate volume head;
Described duplicate volume head judge module is used to judge whether described volume head is the duplicate volume head, if find described duplicate volume head, then triggers described head node locating module, the positioning head node, otherwise trigger described sector scanning module, continue next sector of scanning;
Described head node locating module, be used for releasing the position of described volume head according to the inverse position of described duplicate volume head, again according to each field positioning head node of a described volume position and duplicate volume head, if navigate to described head node, then trigger described file and recover module, the recovery file data, otherwise trigger described sector scanning module, continue next sector of scanning;
Described file recovers module, is used for traveling through all B-that head node comprised that navigates to trees, obtains wherein file and directory information, the recovery file data; Described file recovers module and also is used to search leaf node, each node that the B-tree is read in skew that begins from described head node, judge each field of the node descriptor of the node of reading, if the node type of the node descriptor of the node of reading equals-1, height of node is less than 16, and reserved field equals 0, then be judged as described leaf node, and recovery file data, resolve the archive information that writes down in the described leaf node, decomposite directory file item and archive files item, according to the positional information and the size information recovery file of the record of the data fork in the described archive files item;
Described head node is searched module and is comprised:
The head node judging unit, be used for judging each field of the first gear case of each field of node descriptor of described head node and described head node, if the last node number in the node descriptor of described head node equals 0, node type equals 1, height of node equals 0, the archives number equal 3 and reserved field equal 0, and the root node of the first gear case of described head node is number greater than 0 and less than the node sum, do not use the node number less than the node sum, first leaf segment period is less than the node sum, last leaf segment period and less than the node sum is then thought described head node.
7. HFS+ file system data recovery device according to claim 6 is characterized in that, described volume head is searched module and comprised:
Volume head signature judging unit, be used for when searching described volume, judge the volume head signature of file, 16 systems are that 0x482b and version equal 4 if the volume head of described file is signed, perhaps the volume head of described file 16 systems of signing are that 0x4858 and version equal 5, then are described volume head.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 201110293363 CN102289526B (en) | 2011-09-29 | 2011-09-29 | HFS+file system data recovery method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN 201110293363 CN102289526B (en) | 2011-09-29 | 2011-09-29 | HFS+file system data recovery method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102289526A CN102289526A (en) | 2011-12-21 |
| CN102289526B true CN102289526B (en) | 2013-07-31 |
Family
ID=45335952
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN 201110293363 Active CN102289526B (en) | 2011-09-29 | 2011-09-29 | HFS+file system data recovery method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102289526B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102567507B (en) * | 2011-12-26 | 2013-12-18 | 深圳万兴信息科技股份有限公司 | Method and system for creating tree under MAC |
| CN104751080A (en) * | 2015-04-29 | 2015-07-01 | 山东华软金盾软件有限公司 | USB (Universal Serial Bus) flash disk encryption-based data access method and system |
| CN106844089B (en) * | 2015-12-03 | 2021-01-01 | 阿里巴巴集团控股有限公司 | Method and equipment for recovering tree data storage |
| CN108062357B (en) * | 2017-11-28 | 2020-09-08 | 厦门市美亚柏科信息股份有限公司 | Deleted file recovery method for F2FS file system and storage medium |
| CN109582500B (en) * | 2018-11-26 | 2021-09-03 | 万兴科技股份有限公司 | Data recovery method and device, computer equipment and storage medium |
| CN110659162B (en) * | 2019-09-27 | 2022-10-25 | 厦门市美亚柏科信息股份有限公司 | Data recovery method, device and system of TPSFS file system and storage medium |
| CN111143130B (en) * | 2019-12-25 | 2021-05-25 | 腾讯科技（深圳）有限公司 | Data recovery method and device, computer readable storage medium and computer equipment |
| CN112579336B (en) * | 2020-12-31 | 2022-04-22 | 厦门市美亚柏科信息股份有限公司 | Database exception recovery method and device, computing device and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998026353A2 (en) * | 1996-12-12 | 1998-06-18 | Network Associates, Inc. | Recoverable computer file system |
| CN1959649A (en) * | 2006-09-19 | 2007-05-09 | 珠海金山软件股份有限公司 | Method for rebuilding directory structure and recovering data in NTFS volume |
| CN101937377A (en) * | 2009-06-29 | 2011-01-05 | 百度在线网络技术（北京）有限公司 | Data recovery method and device |
-
2011
- 2011-09-29 CN CN 201110293363 patent/CN102289526B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998026353A2 (en) * | 1996-12-12 | 1998-06-18 | Network Associates, Inc. | Recoverable computer file system |
| CN1959649A (en) * | 2006-09-19 | 2007-05-09 | 珠海金山软件股份有限公司 | Method for rebuilding directory structure and recovering data in NTFS volume |
| CN101937377A (en) * | 2009-06-29 | 2011-01-05 | 百度在线网络技术（北京）有限公司 | Data recovery method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102289526A (en) | 2011-12-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102289526B (en) | HFS+file system data recovery method and device | |
| US9665304B2 (en) | Storage system with fast snapshot tree search | |
| CN102110146B (en) | Key-value storage-based distributed file system metadata management method | |
| US11347443B2 (en) | Multi-tier storage using multiple file sets | |
| CN103748564B (en) | Storage system and method for managing object | |
| CN101937377B (en) | Data recovery method and device | |
| KR102310246B1 (en) | Method for generating secondary index and apparatus for storing secondary index | |
| CN104081391A (en) | Single instantiation method using file clone and file storage system utilizing the same | |
| CN104462389B (en) | Distributed file system implementation method based on classification storage | |
| US11513996B2 (en) | Non-disruptive and efficient migration of data across cloud providers | |
| CN102495777B (en) | Hard disc failure processing method and processing device | |
| CN103473298A (en) | Data archiving method and device and storage system | |
| CN101853275A (en) | Data management method of FAT file system and system | |
| CN103617097A (en) | File recovery method and file recovery device | |
| CN104239438A (en) | File information storage method and file information read-write method based on separate storage | |
| US20180373456A1 (en) | Metadata Load Distribution Management | |
| CN103268291B (en) | The method of persistence index metadata is postponed in flash-memory storage system | |
| CN115098447B (en) | File recovery method and device, electronic equipment and readable storage medium | |
| CN112115002B (en) | Method and device for recovering file from damaged or untrusted mechanical hard disk | |
| CN105493080B (en) | The method and apparatus of data de-duplication based on context-aware | |
| CN100399294C (en) | Method and apparatus for effective data management of files | |
| CN104965835A (en) | Method and apparatus for reading and writing files of a distributed file system | |
| CN102024060A (en) | Method for memorizing files and restoring error deleted files | |
| CN105786653A (en) | File recovery method and system based on FAT32 file system | |
| CN107133334B (en) | Data synchronization method based on high-bandwidth storage system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C53 | Correction of patent for invention or patent application | ||
| CB02 | Change of applicant information |
Address after: 518057 Guangdong city of Shenzhen province Nanshan District Gao Xin Road, room 9 building on the north side of block A901 No. 006 TCL Industry Research Institute building A A Building 8 floor Applicant after: Shenzhen Wondershare Information Technology Co., Ltd. Address before: 518057 Guangdong city of Shenzhen province Nanshan District Gao Xin Road Building A block 8 Building TCL Applicant before: Shenzhen Wondershare Software Co., Ltd. |
|
| COR | Change of bibliographic data |
Free format text: CORRECT: APPLICANT; FROM: SHENZHEN WONDERSHARE SOFTWARE CO., LTD. TO: SHENZHEN WONDERSHARE INFORMATION TECHNOLOGY CO., LTD. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address | ||
| CP03 | Change of name, title or address |
Address after: 850000 Tibet autonomous region, Lhasa City, New District, west of the East Ring Road, 1-4 road to the north, south of 1-3 Road, Liu Dong building, east of the 8 unit 6, floor 2, No. Patentee after: Wanxing Polytron Technologies Inc Address before: 518057 Guangdong city of Shenzhen province Nanshan District Gao Xin Road, room 9 building on the north side of block A901 No. 006 TCL Industry Research Institute building A A Building 8 floor Patentee before: Shenzhen Wondershare Information Technology Co., Ltd. |