Method of cloning the file system of a window web operating system by using a bitmap file

[0002] The present invention relates to a method of cloning a file system of a window web operating system by using a bitmap file, and more particularly to a method of cloning a file system by a bitmap file under the Microsoft Windows NT operating system.

[0003] Clone techniques are intensively used in mass production operations in computer production lines. These techniques commonly make the OS (Operating System) and Source File System Partition (hereinafter referred to as Source Partition) into a compressed file, then clone the compressed file onto every object disk, and then decompress the file, so as to produce object disks identical to the original Source Partition. These clone techniques greatly improve computer mass production efficiency. Further, conventional file clone techniques can also be applied to the preparation of a computer system copy for use in restoring the system when the computer system fails. Conventionally, file clone techniques adopt a regular procedure to compress file data in proper order. This operation speed is slow. Recently, a file clone technique has been developed, which, as shown in FIG. 1, compresses files rapidly without being in conformity with the order of the files. However, under Microsoft's NT Operation System, this file clone technique is based on the File System. This technique compresses the content of the source partition subject to a Master File Table (hereinafter referred to as MFT), forming an Image File, and then decompresses the file after having been cloned to every object disk. During this process, the system inspects all information in the table of contents, finds out all files in the source partition and modifies the MFT in the object partition subject to the information on the size and partition condition included in the object disk. Because the NT File system (hereinafter referred to as NTFS) records file information in multiple addresses, a new partition cloned by means of the aforesaid file clone technique shows different file information at different addresses when the size of the source partition and the size of the object disk are different. This difference destroys the stability and unity of the system, preventing the file clone operation from proceeding, or even causing the partition to crash. Furthermore, the operation procedure of this file clone technique is complicated and slow, and weak in system protection.

[0004] The present invention has been accomplished to provide a file system clone technique, which eliminates the aforesaid drawbacks. The file system clone technique of the invention is to clone data but not the file. Therefore, it is not necessary to re-build the MFT in the object partition, so that the safety and unity of the system are ensured. The method of the present invention greatly increases file clone speed. The advantages of the present invention become more significant when the size of the source partition and the size of the object disk are different. According to one aspect of the present invention, the file system cloning method uses a bitmap file to clone the NT file system. During the data cloning process, few files are changed, and it is not necessary to rebuild the object partition MFT. Further, data access is directly made through the file system. Therefore, the file system cloning speed is high. According to another aspect of the present invention, the file system cloning method does not need to re-construct object partition MFT. Therefore, the procedure does not modify file recording information in the partition, and the safety and unity of NT file system are ensured. According to still another aspect of the present invention, the operation procedure of the file system cloning method of the present invention is simple, and a user can easily complete the clone of a NT file system without knowing the system internal structure.

[0005] FIG. 1 is a schematic drawing explaining the operation of the prior art file system clone technique.

[0006] FIG. 2 is a schematic drawing explaining the operation of the file system clone technique of the present invention.

[0007] FIG. 3 illustrates the operation architecture of the present invention.

[0008] FIG. 4 is a flow chart explaining the procedure of making an image file according to the present invention.

[0009] FIG. 5 is a flow chart explaining the procedure of finding bitmap file according to the present invention.

[0010] FIG. 6 is a schematic drawing showing the compression process architecture according to the present invention.

[0011] FIG. 7 is a flow chart explaining the procedure of decompressing a bitmap file to object partition according to the present invention.

[0012] FIG. 8 is a flow chart explaining the procedure of modifying a bitmap file.

[0013] Referring to FIG. 2, data from Source Partition 2 is stored in Bitmap File (Bitmap Table) 1 in the form of a Data Block, and then the Data Block of Source Partition 2 is compressed into Image File 3 subject to Bitmap File 1. After Image File 3 has been duplicated onto the target disk, compressed Bitmap File 1 of Source Partition 2 is decompressed in Object Partition 4 in the Object disk. Then, Bitmap File 1 is modified according to the size variation from the Source Partition 2 to Object Partition 4, subject to the size of the Object Partition and physical parameters of the Object Disk.

[0014] The clone technique of the invention is to clone the File System of Source Partition 2 to Object Partition 4 by Bitmap File 1, enabling the data in Object Partition 4 to be maintained in conformity with the data in Source Partition 2 after decompression. The clone technique includes the following two procedures as shown in FIG. 3.

[0015] (1) Arrange the data in Source Partition 2, then set up the data into an Image File subject to one Bitmap File of the data, enabling the initial position of the Image File 3 to be stored in an Image File Header Structure 31, which is stored with certain important physical parameters of Source Partition 2, such as total sectors, partition information, etc.

[0016] (2) Read out the Image File 3 and resume storage data to the Object Partition 4 of one Object Disk. During reading, the parameters in the Image File Header Structure 31 are read first, then the sizes of the Source Partition 2 and the Object Partition 4 are compared, the Bitmap File and related parameters are modified subject to the size of the Object Partition 4, the modified data is written into the Object Partition 4, and the content of the data block of the Source Partition 2 is cloned to the Object Partition 4 of the Object Disk.

[0017] Because the Bitmap File exists in the file system partition, equivalent to the FAT table of a FAT format, when searching the address of Bitmap File, as shown in FIG. 4, the position of the MFT Table is obtained from the Boot sector of Source Partition (401). The record of the Bitmap File from the first 20 records in MFT Table (402) is then searched to find the physical address and size of the Bitmap File from the records (403), so as to obtain the actual address and size of the Bitmap File, and the useful data can thus be read out from Source Partition, preventing useless data from appearing in the Image File, so that the size of Image File can be minimized to improve hard disk clone speed.

[0018] When making the Image File, as shown in FIG. 5, the data in the first sector is read from Source Partition (501), the Parameter Block of BIOS parameters (502) is initialized, and the Parameter Block is written into the Boot Sector in Source Partition (503), the file system data is written into the Bitmap File (504), the Bitmap file is read in and stored in a Temporary File in Buffer (505), and a judgement is made as to whether the Bitmap File reading action has been terminated (506). If the Bitmap File has all been read out, the largest cluster number from the file data is changed to the smallest sector number (507), the rest of the data in the Bitmap File is written into Buffer (508), and then the system returns to the step of reading sector data from the Source Partition. If the Bitmap File reading action continues, one data block is read from Bitmap File subject to record number (509), the corresponding cluster number in the Image File is written subject to the data message in the data block (510), the record number of the data block is added, the largest useful data cluster number (512) is recorded, and the system then returns to the step of reading sector data from Source Partition.

[0019] The invention divides all useful data in the Source Partition into several Data Blocks, as illustrated in FIG. 6, compresses every Data Block, and then stores compressed data of every Data Block into Image File. This procedure enables the size of the Image File to be minimized.

[0020] When cloning the File System from the Source Partition to the Object Partition, the Image File is decompressed, and then Bitmap File of the Source Partition is modified subject to the size of the Object Partition. The decompression processing procedure is shown in FIG. 7. When proceeding to the decompression processing procedure, the system reads the Image File Header Structure of the Image File (701), which is stored with certain important physical parameters of Source Partition 2 that describe the characteristics of the Source Partition such as total sectors, partition information, etc. Then, the value of “n” is set subject to the number of data blocks in the Image File (702), and the step of judging whether the set value “n” surpasses zero or not is carried out. If the answer is positive, the system reads the data from the corresponding Data Block (704), and then judges the Data Type of the data (705). If the data is Boot data (706), the system immediately modifies the BIOS Parameter Block of the Object Partition (707), and then reserves the modified result (708). If the data is of Boot C data (709), File System data (710), or regular data (711), the system writes the data, which contains a Partition message, write-in address and data content, etc., reserves the Parameter Block into the data sector of the Object Partition (712), sets Data Block number n=n−1, ends data processing (713), and repeats the aforesaid processing procedure to read the Image File Header Structure of the Image File again. The data decompression processing procedure is terminated when the content of all Data Blocks of Image File has been completely processed (i.e., n≦0).

[0021] Bitmap File modification includes the following three modification conditions subject to the size of the Object Partition obtained:

[0022] (1) When Object Partition Source≦Partition, the system simply sets a Bitmap File end sign in the original Bitmap File at the position which represents the end of the Object Partition.

[0023] (2) When Object Partition>Source Partition and the original Bitmap-File represents the position of the end of the Object Partition, the system clears all redundant data before the end of Object Partition, and then sets a Bitmap File end sign at the position of the end of the Object Partition.

[0024] (3) When Object Partition>Source Partition but the original Bitmap File does not represent the position of the end of the Object Partition, the system finds a new position in the Object Partition, sets a new Bitmap File, clones the content of the original Bitmap File to the-new position, clears all redundant data before the end of the Object Partition, and then sets a Bitmap File end sign in the position of the end of the Object Partition.

[0025] When modifying the Bitmap File, as shown in FIG. 8, the system judges if Object Partition>Source Partition (801). When Object Partition≦Source Partition, a File end sign is set in the original Bitmap File (802);when Object Partition>Source Partition, the system judges if the Bitmap File of the Source Partition can represent the Bitmap File end sign of Object Partition or not, so as to clear from the original Bitmap File all redundant data before the File end sign (804) in case the answer is positive. If the Bitmap File of the Source Partition cannot represent the Bitmap File end sign of the Object Partition, the system finds a new Bitmap File position, clones the Bitmap File of Source Partition to the new Bitmap File position, and then clears redundant data and sets a File end sign (805).

[0026] In an application example of the present invention, the size of Source Partition is 200 Mb (Mega byte), and it is divided into 400 Data Blocks including 100 useful Data Blocks. When making an Image File, Boot sector data is written into the Image File, and at last, important physical parameters in the Source Partition such as Total Sectors, Partition Information, etc., are written into Image File Header Structure and thus the Image File is done.

[0027] In the aforesaid application example, if the size of the Object Partition is 150 Mb when restoring the Source Partition File to the Object Partition, the system reads the total number of Data Blocks the from Image File Header Structure of Image File, restores in proper order the Boot sector data, the data of 100 Data Blocks, and the Bitmap File, and then sets the Partition End Sign at 150M. If the size of Object Partition is 300 Mb, the system sets the Partition End Sign at 300 Mb, and clears from the Bitmap File redundant data between 200 Mb and 300Mb.

[0028] It is to be understood that the drawings are designed for purposes of illustration only, and are not intended for use as a definition of the limits and scope of the invention disclosed.