Generating differences between archives using generic syntax

Abstract

The techniques disclosed herein generate a minimum size delta archive. Thus, the bandwidth of storing or transmitting archives, the storage device, and the processing cost are reduced. In some configurations, the delta archive is generated using particular knowledge of the structure of the source archive and the target archive from which it originates. In particular, a tokenization engine of a specific archive identifies data blocks and load files within each archive. A scheme for generating a load file from a data block and for generating a data block from the load file is identified as a scheme for decompressing the file, connecting the data block, and generating a binary delta that converts an older version of the file to a newer version, and stored in a manifest file. These schemes are combined by replacing the inputs of the schemes with the outputs of the other schemes. A composite scheme reconstructs a target archive using inline data and data acquired from a copy of a source archive.

Description

Background Art

[0001] The number of computing devices in the world is increasing, as is the average size of software applications and the number of software applications that people use on a daily basis. The increase in computing ubiquity has brought many benefits, but one of the drawbacks is that the cost of keeping software updated has increased significantly. Software updates are primarily distributed over networks. Therefore, bandwidth costs are directly related to the size of the software updates. As the size of software updates increases, storage and processing costs also increase. These costs are particularly significant for computing devices with limited or expensive computing resources, such as wearable computing devices, smart home devices, and other Internet of Things (IoT) devices. The disclosures made herein are presented with respect to these and other considerations.

[0002] It is with respect to these and other considerations that the disclosure made herein is presented. Summary of the invention

[0003] The technology disclosed herein generates differential archives of minimum size. Therefore, the bandwidth, storage and processing costs of storing or transmitting archives are reduced. In some configurations, differential archives are generated using specific knowledge of the structure of the source archive and the target archive from which they are derived. Specifically, an archive-specific tokenization engine identifies data blocks and payload files within each archive. The recipes for generating payload files from data blocks and generating data blocks from payload files are identified and stored in the manifest file, as are the recipes for decompressing files, connecting data blocks, and generating binary differences that convert old versions of files to new versions. These recipes are combined by replacing the input recipes with the outputs of other recipes. Composite recipes use inline data and data obtained from source archive copies to reconstruct the target archive.

[0004] A software archive is a file that contains other files. Examples include TAR, ZIP, WIM, and CAB files. A software application update is an example of a software archive. Application updates generated using the disclosed techniques can be installed in a shorter time and using fewer computing resources than block-based differential updates. Although this document primarily refers to software updates, any other type of software archive is equally contemplated. For example, software archives are also used to back up or transfer groups of files while maintaining the directory structure.

[0005] In addition to the features and technical advantages explicitly described above, the features and technical advantages will be apparent by reading the following detailed description and reviewing the associated drawings. This summary is provided in a simplified form to introduce a series of concepts that will be further described in the detailed description below. This summary is not intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used as an aid to determine the scope of the claimed subject matter. For example, the term "technology" may refer to (multiple) systems, (multiple) methods, computer-readable instructions, (multiple) modules, algorithms, hardware logic and / or (multiple) operations as allowed by the context described above and throughout the text. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The detailed description is described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. The same reference numerals in different drawings indicate similar or identical items. Reference to a single item of a plurality of items may use reference numerals with letters in an alphabetical sequence to refer to each individual item. General references to items may use specific reference numerals without an alphabetical sequence.

[0007] Figure 1 The generation of an example differential archive from a source archive and a target archive is shown.

[0008] Figure 2 An example differential archive is shown being applied together with data from a source archive to reconstruct a target archive.

[0009] Figure 3 Example data blocks contained in the source archive and the target archive are shown.

[0010] Figure 4A An example difference archive is shown.

[0011] Figure 4B An example differential archive is shown being applied with data from a copy of a source archive to generate a copy of a target archive.

[0012] Figure 5 is a flow chart of an example method for applying differential archives to generate a target archive copy.

[0013] Fig. 6A Shown is the expansion and tokenization of example source and target archives into portions of a differential archive generation.

[0014] Figure 6B An example tree showing data chunks and payload files expanded from an archive.

[0015] Figure 7 The generation of binary differentials from payload files in a source archive and a target archive is shown.

[0016] Figure 8 is a flow chart of an example method for generating a differential archive.

[0017] Fig. 9 is a flow chart of an example method for generating a composite archive.

[0018] Fig.10 is a computer architecture diagram illustrating an example computer hardware and software architecture for a computing system capable of implementing various aspects of the techniques and methods presented herein.

[0019] Fig.11 is a diagram illustrating an example distributed computing environment in which various aspects of the techniques and methods presented herein can be implemented. DETAILED DESCRIPTION

[0020] Some software updates are distributed in the form of stand-alone installation packages that completely replace the existing version of the software. In these scenarios, all data from the existing version is removed from the system, and the new version is installed entirely from the update package. In these scenarios, even if the only change to the existing version is a minor modification to a single file, the entire new version needs to be downloaded. For example, when using stand-alone installation technology, a minor version update of an operating system may require the download and installation of the entire operating system. In addition to higher bandwidth and processing costs, installation times may also be long due to the necessity to uninstall and reinstall a large number of components.

[0021] An improvement over stand-alone updates is to package updates as "deltas." Deltas store the changes that occurred compared to the previous version of the software. Differential updates take advantage of the fact that an incremental version of a software application may share a large portion of its data (e.g., 95%) with the previous version. When installing a differential update, data is obtained from the differential update itself and from the local computing device. There are many techniques for generating deltas. For example, block-based deltas perform a block-by-block binary comparison between the new update and the previous version's update. When a match is found, the matching block is replaced in the new update with a reference to that block in the previous version's update.

[0022] Block-based differencing is an improvement over distributing standalone installation packages. However, block-based differencing is not efficient in common scenarios such as compressed files included in updates. File compression has the effect of propagating even small changes throughout the file, significantly limiting the number of blocks that can be reused. Block-based differencing also has difficulties when the data included in the update is not generated in a certain order. If the files in two updates appear in different orders, the blocks may not match unless special care is taken to adjust the block alignment according to the file order. Due to these deficiencies, the differential updates generated by block-based binary comparisons are larger than necessary, resulting in additional bandwidth costs, processing costs, and increased installation time.

[0023] In order to solve the above problem and other problems, a technology for generating differential archives from a source archive and a target archive using a common syntax has been developed. When such a technology is developed, the differential archive can be extended to create a copy of the target archive using inline data and data obtained from a local copy of the source archive. The common syntax is used to describe the contents of the source archive and the target archive. These descriptions are then used to create a scheme for recreating parts of the target archive from the data stored in the local copy of the source archive. As referred to herein, an archive refers to a file containing other files. Examples of commonly used archives include .tar files and ext4, which is a Linux file system.

[0024] Most archives are physically laid out as a series of "chunks", which are areas of the archive defined by byte offsets and lengths. Files that can be extracted from an archive are called "payload files", and may be stored in a single chunk or distributed across multiple chunks. Archive metadata may also be stored in chunks, for example, a header storing information about the payload file, such as the file name, file size, or whether the file is compressed.

[0025] To generate a differential archive, the differential generation engine first identifies the data chunks and payload files contained in the source and target archives. The differential generation engine can store this information as a series of data chunk tokens and payload file tokens in the source and target manifest files. The differential generation engine then adds a scheme to each token that describes how the data referred to by the token is generated with reference to the data referred to by other tokens.

[0026] For example, a given payload file may be split into multiple data blocks (e.g., in an ext4 file system). The differential generation engine creates a data block token in the manifest file for each of the data blocks. The differential generation engine also creates a payload file token in the manifest file for a given payload file. Then, for each of the data block tokens, the differential generation engine may create a scheme describing how to generate the corresponding data block of the token from the payload file. The differential generation engine may also create a scheme describing how to generate a given payload file from the data blocks for the payload file token.

[0027] More complex archive layouts are handled by nesting schemes. Nested schemes generate intermediate results that are further transformed by additional schemes. For example, the payload file may be compressed, in which case two schemes may be used to extract the payload file - one scheme that generates a compressed file from the data blocks, and another scheme that decompresses the result of the first scheme. Additional nesting levels may be required. For example, if the payload file is itself an archive, the entire delta generation process can be recursively applied to that sub-archive.

[0028] When a manifest file containing data chunk tokens, payload file tokens, and a scheme is created for two different archives, the differential generation engine can compare the contents of the manifest to identify when data from the source archive can be used to generate data that appears in the target archive. By comparing hash values, exact matches for data chunks and / or payload files can be identified. When an exact match for a data chunk is found, the data chunk can be omitted from the differential archive and replaced using a scheme for obtaining the same data directly from the source archive. When a payload file is an exact match, a composite scheme can be created that uses the data chunks from the source archive to create a payload file, which is then used to recreate the data chunks that store the payload file in the target archive.

[0029] Payload files that do not fully match can still be used to reduce the size of differential archives. For this reason, the differential generation engine applies differential compression to convert the version of the payload file in the source archive into the version of the payload file in the target archive. During differential generation, differential compression performs binary differential operations on the payload files of the two versions. The resulting binary differential is stored in the differential archive, and the scheme for applying the binary differential is stored in the differential list. When applying differential archives, the binary differential is applied to the payload file of the source archive version to generate the payload file of the target archive version. The result can be used as a parameter to another scheme, for example, in order to reconstruct data blocks from the target archive. Differential compression increases the number of files that can participate in scheme replacement, thereby increasing the number of opportunities for reusing the data stored in the source archive.

[0030] Each archive is processed using an archive-specific tokenization engine that understands the file layout within the archive, including which payload files can be extracted, which data blocks are used to create each payload file, the location of the data blocks within the archive, whether the payload files or data blocks are compressed and how they are compressed, etc. The tokenization engine converts this archive-specific information into a common syntax in the form of tokens. By describing archive-specific information with tokens that are independent of the archive type and file type, schemes from different types of archives can be combined. In addition, adding support for additional archive types or file types only requires adapting the archive-specific or file-specific information to the common syntax. When adapting archive-specific or file-specific information to the common syntax, existing scheme combinations and differential generation algorithms can be applied.

[0031] Figure 1 A differential generation engine 130 is shown generating a differential archive 140 from a source archive 110 and a target archive 120. The differential archive 140 may be distributed to one or more computing devices for expansion and application.

[0032] The differential generation engine 130 may be used (e.g., by an organization) to create a differential update that updates an installed version of a software application to a newer version of the software application. In this scenario, the source archive 110 is an update that is used to install an existing version of a software application, and the target archive 120 is an update that upgrades the software application to a newer version. The source archive 110 may be an archive of an initial installation package that was used to execute the software application. The difference archive 140 is a differential update that creates a copy of the target archive 120 using inline data and data extracted from a copy of the source archive 110. The software update module on the computing device may then use the reconstructed target update to upgrade the software application to the newer version.

[0033] Figure 22 shows a differential apply engine 230 that applies the differential archive 140 together with data from the source archive copy 210 to reconstruct a target archive copy 220 of the target archive 120. The differential apply engine 230 is typically used by a computing device 250. As described above in conjunction with Figure 1 As discussed, differential apply engine 230 can be part of a software update module that uses data contained in a copy of a source update that already exists on computing device 250 to expand a differential update into a target update. The software update module can then apply the target update. Using differential archive 140 in this manner can save the cost and time required to download the entire target update. Differential apply engine 230 can also use data from an installation package of an existing version of a software application.

[0034] Figure 3 Data blocks contained in source archive 110 and target archive 120 are shown. Different archive formats may store payload files in different ways. As shown, source archive 110 has four data blocks 310 - two header blocks and two body blocks: header 320A for file A block, file A block 330A, header 340 for file B block, and file B block 350. Target archive 120 contains target data blocks 312, including header 320B for file A block, file A block 330B, header 342 for file B' block, file B' block 352, header 362 for file C block, and file C block 372.

[0035] Figure 4A The contents of a differential archive 140 are shown. The differential archive 140 contains a combination of tokens and inline assets. As referred to herein, a token is data stored in an archive or a reference to that data. For example, a token may refer to data, such as a data block 350, which is part of a source archive 110. A token may also refer to a payload file, which may be extracted from the archive, or to a scheme for creating data from the data referred to by other tokens. In addition to referencing data stored in an archive, tokens themselves may contain data, which are referred to as inline assets. Inline assets refer to headers, binary deltas, or even entire files stored in the differential archive 140 that are needed to recreate a target archive 120.

[0036] As shown, differential archive 140 contains local files 400, which include file A token 330 and file B token 350. These tokens refer to payload files that may be obtained from outside the differential archive (eg, from source archive copy 210). Figure 4AAlso included are chunk tokens 412, which list all chunk tokens that are present in target archive 120 and that will be reproduced when differential archive 140 is applied to reconstruct a copy of target archive 120. Specifically, differential archive 140 contains header 420 for file A tokens, file A tokens 430, header 442 for file B' tokens, file B' tokens 452, header 462 for file C tokens, and file C tokens 472.

[0037] Inline assets 450 include header 320 for file A, header 342 for file B', binary difference 454 from file B to file B', header 362 for file C, and file C 372. Some of the inline assets 450 are verbatim copies of files that appear in target archive 120 but not in source archive 110, such as file C 372. File C is copied in its entirety from target archive 120 to differential archive 140 when there is no corresponding data block or payload file in source archive 110. Other inline assets are binary differences that can be used to convert a version of a file found in source archive 110 to a version of the same file found in target archive 120, such as difference 454. Archive headers describe files within an archive and are therefore specific to that archive. Because headers are specific to the archive in which they appear, they are not transferable to a different archive. This is why, even though file A and file B already had headers in source archive 110 , header 320 for file A as well as headers 342 and 362 are included inline in difference archive 140 .

[0038] Figure 4B The differential archive 140 is shown being applied with data from the source archive copy 210 to generate the target archive copy 220. To make the target archive copy 220 an exact binary match with the target archive 120, the differential apply engine 230 iterates through each of the block tokens 412, which applies a block scheme 414 to reconstruct each of the target data blocks 312. As shown, the file A header token 420 is associated with a scheme 480A, which copies the header 320 for file A from the inline asset 450 into the header 322 for the file A block. The header 320 for file A is made into an inline asset because it is not found in the source archive copy 210.

[0039] File A token 430 is associated with a scheme 482A that copies the local asset (in this case, block 331 of File A) into File A block 332. Scheme 482A may refer to File A token 330 in order to determine how to obtain payload file 331.

[0040] The file B′ header token 442 is associated with a copy inline asset scheme 480B. The copy inline asset scheme 480B causes the header 342 for file B′ to be copied directly from the inline assets 450 of the differential archive 140 into the header 342 for the file B′ chunks of the target archive copy 220.

[0041] File B' token 452 is associated with apply differencing scheme 484A. Apply differencing scheme 484A takes data from file B of source archive copy 210 and applies binary differencing 454 to generate a new version of file B. Some or all of the new version of file B is then stored as file B' chunk 352.

[0042] The file C header token 462 and the file C token 472 are associated with the copy inline asset schemes 480C and 480D, respectively. File C does not exist in the source archive 110, so it must be stored in its entirety in the differential archive 140. The copy inline asset schemes 480C and 480D copy the header 362 for file C and the file C 372 in the inline asset 450 to the header 362 for file C and the file C block 372 in the target archive copy 220, respectively.

[0043] The resulting target archive copy 220 is a perfect binary copy of the target archive 120 that is indistinguishable from the original copy. In some configurations, this is confirmed by comparing the hash value of the target archive 120 stored in the difference archive 140 with the hash value calculated from the target archive copy 220. If the source archive and the target archive are software updates, the software update module can apply the target archive copy 220 to update the software application to the new version.

[0044] Figure 5 1 is a flow chart of an example method 500 for applying a differential archive 140 to generate a target archive copy 220. The method 500 begins at operation 502 by reading a header of a differential archive 140. The header of the differential archive 140 may include a list of tokens and inline assets contained in the differential archive 140. The header of the differential archive 140 may also include a hash value of the target archive 120.

[0045] The method continues to operation 504 by verifying that the local asset (eg, local file 400) is available in the source archive copy 210. If the source archive copy 210 is not available, an error is raised.

[0046] Next, at operation 506, as described above in conjunction with Figure 4B As discussed, the scheme associated with block token 412 applies.

[0047] Next, at operation 508, the target archive copy 220 is assembled and verified.

[0048] Fig. 6A An archive expansion and tokenization engine 630 is shown that expands and tokenizes the source archive 110 and the target archive 120 as part of differential archive generation. The archive expansion and tokenization engine 630 may be part of the differential generation engine 130.

[0049] The archive extension and tokenization engine 630 may extract payload files and chunks from the source archive 110. For example, the archive extension and tokenization engine 630 may generate a source archive file 640 from the source archive 110. The archive extension and tokenization engine 630 may also generate a source archive manifest 660 based on metadata included in the source archive 110. The archive extension and tokenization engine 630 similarly processes the target archive 120 to generate an extended target archive file 670 and a target archive manifest 690.

[0050] Figure 6B An example of data blocks and payload files expanded from archives 110 and 120 is shown. The expanded source archive file 640 includes a source block folder 642, a source payload folder 650, and a source binary large object (blob) folder 651. These folders are used to store files during differential generation. The archive expansion and tokenization engine 630 can perform binary comparisons, extract blocks, combine blocks, and perform other operations while generating a differential archive 140 using the expanded blocks and payload files stored in these folders. As shown, the source block folder 642 contains a file A block 643, a file B block 644, a file A header block 646, and a file B header block 647. These files are derived from the source block 310 of the source archive 110. The source payload folder 650 contains a payload file A 653 and a payload file B 654. The payload file A 653 and the payload file B 654 are the same as the files extracted from the source archive 110 using the archive expansion tool. In some scenarios, the archive extension and tokenization engine 630 constructs payload file 653 and payload file 654 from block 643 and block 644, respectively. In other scenarios, the archive extension and tokenization engine 630 uses archive-specific archive extension tools to extract the payload file, such as using tar to extract the payload file from a .tar file.

[0051] The extended target archive 670 similarly includes a target data block folder 672, a target payload folder 680, and a target blob folder 691. The target block folder 672 contains files derived from the target data block 312 of the target archive 120. Specifically, the target block folder 672 includes a file A block 673, a file B' block 674, a file C block 675, a file A header block 676, a file B' header block 677, and a file C header block 678. The target payload folder 680 similarly includes a payload file A 683, a payload file B' 684, and a payload file C 685.

[0052] The source blob folder 651 and the target blob folder 691 are used to store blobs as solution results, and these blobs can be provided as parameters to different solutions.

[0053] The archive extension and tokenization engine 630 may generate a manifest file that describes the contents of the archive. For example, the archive extension and tokenization engine 630 may generate a source archive manifest 660 from the source archive 110 and a target archive manifest 690 from the target archive 120. As described in more detail below, data from the source archive manifest and the target archive manifest may be combined to generate a differential archive that uses data from a copy of the source archive to provide a payload file that is contained in the target archive.

[0054] The manifest file contains tokens that describe the contents of the archive. For example, the manifest file may contain tokens that describe payload files that can be extracted from the archive. For example, source archive manifest 660 may contain payload file tokens that describe payload file A 653 and payload file B 654 in source archive 110.

[0055] Archives typically store payload files as a single data block within the archive - a single contiguous storage block. However, archives often split payload files into data blocks distributed throughout the archive, rather than storing payload files in a single data block. Data block tokens describe data blocks found in the archive. For example, source archive manifest 660 may include data block tokens describing file A block 643, file A header block 646, and other data blocks in source archive 110.

[0056] A token in a manifest file may be associated with a scheme that describes how to obtain the token item. A scheme may reference a data block or a payload file. For example, a data block token may include a scheme that refers to a payload file in source archive 110, and a payload file token may include a scheme that refers to one or more data blocks in source archive 110. The manifest file may also include properties of the archive itself, such as the name of the archive, the date and time it was created, a version number, etc.

[0057] Each chunk token includes an identifier (e.g., "HeaderChunkA"), an offset from the start of the archive, and the length of the chunk. Each chunk token may also include one or more hash values ​​that are binary compared to different chunks (usually from different archives). Hash values ​​are typically generated by cryptographic hash functions such as SHA256 or MD5. These algorithms convert a chunk or file into a fixed-length numeric string that uniquely identifies the chunk or file, respectively. Hash values ​​can have various lengths, such as 80 bytes, 256 bytes, 1024 bytes, etc.

[0058] As briefly described above, the schemes included in the manifest file describe how to obtain data blocks and payload files from the corresponding archive. A scheme can have an identifier, a type, an operation to execute the scheme, and other scheme-specific input and / or output parameters. The scheme identifier can be used by one scheme to refer to another scheme, allowing schemes to be nested or otherwise combined. The scheme type indicates the type of data generated by the scheme, such as a data block, a payload file, or a blob of bytes in the case of an intermediate scheme. The operation indicates how to execute the scheme. Examples include copying a single data source to generate an output, concatenating data from multiple data sources, collecting data from a specific area of ​​a data source, and transforming a data source (e.g., compressing, decrypting).

[0059] For example, a scheme with a "CopyFile" operation can generate a payload file from a single data block. As shown, the "CopyFile" scheme performs a binary copy of the contents of FileA.chunk 643 to generate a copy of payload file A 653. One of the input parameters to the "CopyFile" scheme may identify the source data block, while the output parameter may identify the name of the payload file. Schemes for creating payload files from multiple data blocks and other operations will be discussed below.

[0060] In some configurations, a chunk token includes an identifier, a name, a type, an offset within the source archive 110, a length, and one or more hash values. The chunk token identifier can be used to reference the chunk token from a payload file or schema, allowing a payload file schema to describe how to generate a payload file by referencing the chunk. The token name can be descriptive, for example, it might be used for debugging purposes. The chunk token offset indicates the byte offset into the archive file 110 of the chunk, and the length indicates the number of bytes in the chunk.

[0061] In some configurations, the payload file token contains similar attributes as the data chunk token, including an identifier, type, length, and hash value. The payload file token may also include a location on disk where the archive extension and tokenization engine 630 copied the corresponding payload file, e.g., as part of the extended source archive file 640. This file location allows the differential generation engine to locate the payload file when creating a differential archive.

[0062] In some configurations, the manifest file containing the data block token and the payload file token is further processed to generate a scheme describing how to obtain the referenced data block and payload file. For example, a scheme can be added to the data block, which indicates how to obtain the data block from the payload file. When the payload file is stored in a single data block, the scheme can be a "copy" scheme, which obtains the data block by making a copy of the payload file. The "copy" scheme can have a single parameter, which points to the payload file. In some configurations, the parameter to the "copy" scheme is a payload file token describing how to obtain the associated payload file. In other embodiments, additional schemes are layered above or below the scheme for obtaining the payload file, for example, by adding a "decompression" scheme, which first decompresses the payload file before the "copy" scheme copies the resulting bytes into the data block. As discussed in more detail below, if the payload file is generated from multiple data blocks, a more complex "region" scheme can be used to extract specific portions of the payload file used to generate the data block.

[0063] In some configurations, the payload file scheme describes how to construct a payload file. When initially generated by the archive expansion and tokenization engine 630, the payload file scheme refers to the contents of the same archive. If the payload file is stored in an archive in a single data block, a "copy" scheme can be used to generate the payload file, similar to how the "copy" scheme is used to generate data blocks from the payload file. Specifically, the payload file can be obtained by copying all bytes in the bytes of a single data block. However, if the payload file is stored in an archive in multiple data blocks, the "connection" scheme takes multiple data blocks from any position of the entire archive and connects them into a single payload file. The "connection" scheme can have two or more parameters. Some of the parameters can be data block tokens, for example, a copy scheme indicating where in the archive to copy a portion of the payload file. Other parameters can be tokens with a "blob" type, which represent the result of a nested operation, such as a decrypted data block. Other parameters can be tokens that generate padding, such as a "fill" scheme that produces a defined number of synthetic bytes, such as a defined number of zeros.

[0064] A padding scheme is included to ensure complete binary correspondence between the target archive 120 and the target archive copy 220. One of these placeholder byte streams may be needed when the archive is not self-describing of all of the bytes it contains. To accommodate this possibility, the differential generation engine 130 can evaluate the generated archive manifest and the archive from which it is derived to ensure that every byte in the archive is described by the manifest. When bytes in the archive are found not to be described by the manifest, synthetic byte streams such as "all zeros" and "padding" can be inserted to accommodate them.

[0065] As briefly described above, the "region" scheme defines how to generate a data block from a specific region of a payload file. In some configurations, the "region" scheme has three parameters: a parameter identifying the payload file containing the data block, an offset parameter defining the starting position of the data block within the payload file, and a length parameter indicating the length of the data block within the payload file.

[0066] One of the advantages of the disclosed embodiment is the ability to combine schemes, thereby improving the ability to reuse existing data when distributing differential archives. For example, a data chunk token may include a "region" scheme that refers to a payload file. In order to make the payload file available to a program that extracts the data chunk, a nested "copy" scheme may be used to obtain the payload file from the archive. The nested "copy" scheme may include the file location of the payload file obtained by the archive expansion and tokenization engine 630.

[0067] Additional schemes may be added to the system as needed to implement a complete description of how to obtain the items referenced by the tokens. For example, if the final consumer of the differential archive is a computing device that uses a "big endian" encoding for numbers, and the source archive uses a "little endian" encoding for storing numbers, then a "big endian" scheme may be inserted between the "region" scheme for the data block tokens and the "copy" scheme for the payload files to convert the payload files returned by the "copy" scheme into "big endian" format.

[0068] As discussed above, archive extension and tokenization engine 630 generates source archive manifest 660 and target archive manifest 690 and associated extended archive files 640 and 670. Archive extension and tokenization engine 630 also processes manifest files to add schemes for obtaining items listed therein. Initially, the scheme refers to other items contained in the same archive. For example, a scheme within a source archive manifest refers to other schemes and tokens within source archive manifest 660, or refers to an extended source archive file 640 extracted from source archive 110. However, in order to create a differential archive that extends the payload files of target archive 120 with data contained in source archive 110, a composite scheme is created by combining the schemes found in target archive manifest 690 with the schemes found in source archive manifest 660.

[0069] For example, the composite scheme used to generate the data chunks of the target archive may include the "region" scheme from the target archive manifest 690, but with the payload file token parameter from the source archive manifest 660 replacing the payload file token from the target archive manifest 690. The replacement may be made based on a determination that the same payload can be found in both the source archive 110 and the target archive 120, e.g., based on a comparison of file names, file lengths, hash values, etc. The resulting composite scheme may be stored in a differential archive manifest of the differential archive.

[0070] When expanding a differential archive, the computing device may execute the composite scheme by extracting the referenced payload file from the copy of the source archive and applying the region scheme to obtain the desired data blocks.

[0071] In some cases, source archive 110 and target archive 120 have identical blocks, in which case the composite scheme may include a scheme for the target block that refers to a scheme for the same block stored in source archive 110. The data blocks generated by applying the composite scheme may be used to reconstruct payload files found in both source archive 110 and target archive 120.

[0072] In other cases, the data blocks referenced in the target archive manifest are different from any of the data blocks stored in the source archive 110, but both data blocks can be derived from a payload file that can be generated by the source archive 110 and the target archive 120. In these cases, the differential generation engine 130 can generate a "composite" scheme that generates the payload file. Some of the parameters of the "composite" scheme can refer to data blocks found in the target archive 120, and these data blocks are copied to the differential archive as inline assets. Other parameters of the "composite" scheme can refer to data blocks found in the source archive 110. For example, if a data block in the source archive 110 is available, the "copy" scheme can refer to such data block. In other scenarios, a "regional" scheme can be used to obtain data blocks from the payload file of the source archive 110.

[0073] Regardless of how the data block is obtained, the block found in the target archive 120 is reconstructed using the data stored in the source archive copy 210. This avoids having to retransmit the block found in the target archive 120. When the block is reconstructed from the source archive copy 210, the block can be applied to reconstruct the payload file found in the target archive 120. The data block can also be used to create the target archive copy 220, which can perform similar operations as a normal archive, and it can be used for other operations such as installing applications.

[0074] If the blocks or payload files from the source archive 110 and the target archive 120 are determined to be different, a binary difference may be calculated using the difference generation engine 130 and stored in the difference archive 140. The binary difference is generated by performing a binary comparison between the first file (or block) and the second file (or block), thereby generating a difference file (or block) that encodes the difference between the two files. An "apply difference" scheme may be inserted between the scheme for the target payload file and the scheme for obtaining data from the source archive 110, so that the output of the scheme for obtaining data from the source archive 110 is provided to the apply difference scheme, and the output of the apply difference scheme is provided to the target payload file scheme. When the apply difference scheme is applied, it applies the binary difference stored in the difference archive 140 to the result of the scheme for obtaining data from the source archive copy 220. The result is the block originally identified in the target archive 120.

[0075] Composite schemes may include additional layers and additional types of schemes. For example, a composite scheme may include a decompression scheme. A decompression scheme may be used when the payload file is compressed within the source archive 110. One use of the decompression and compression schemes is to access a payload file compressed using one compression technique (e.g., gzip) and store it in an archive using a different compression technique (e.g., zstd compression).

[0076] For example, the "Zstd compression" scheme can be nested between the "connection" scheme, which provides a payload file based in part on the data blocks found in the source archive copy 210, and the "region" scheme, which stores the data blocks in the target archive. The effect of inserting the "Zstd compression" scheme is to compress the payload file provided by the "connection" scheme before splitting the compressed file into multiple data blocks. In some cases, different types of compression can be applied to the same payload file in different archives. In this case, a corresponding "Zstd decompression" (or "Gzip decompression") scheme can be added between the "Zstd compression" scheme and the "connection" scheme to take into account the different types of compression. In this embodiment, the "connection" scheme reconstructs the payload file in a compressed form based in part on the data blocks from the source archive copy 210. The "decompression" scheme decompresses the compressed payload file into an uncompressed payload file. The "compression" scheme recompresses the payload file according to the compression type used by the target archive 120. Then, the "region" scheme can be used to obtain the data blocks of the recompressed payload file for the differential archive 140.

[0077] In some configurations, the archive concatenates multiple payload files into slices before compressing them. In this case, a scheme can be introduced into a scheme chain scheme that decompresses the concatenated files before splitting them from the slices into individual payload files. The opposite operation can also be included as a scheme - collecting the payload files into slices and compressing them, after which a replication scheme or a zone scheme can be used to transfer the contents of the compressed slices to data blocks. More complex situations can arise when one of the payload files included in the slice is truncated to fit within the slice, while the rest of the file is stored in a different slice. To handle this more complex situation, a scheme can be introduced to decompress each slice, and another scheme can be introduced to splice together the two parts of the payload file split between the slices. A scheme that performs the opposite operation can also be introduced.

[0078] Figure 7How to generate binary difference from the payload files in the source archive and the target archive is shown. The difference generation engine 730 is a component of the difference generation engine. The difference generation engine 730 compares the payload files and / or data blocks from the source archive and the target archive to determine whether there are any binary differences between them. Binary difference is the binary difference between two files. Binary difference can be described as a sequence of bytes and instructions, and these instructions describe how to apply those bytes to a file in the file. Applying binary difference to a file in the file produces another file. The binary difference calculated by the difference generation engine 730 is then added to the difference archive file 740. Similarly, the list entry for the binary difference is added to the difference archive list 760.

[0079] Binary differencing can be employed when two payload files with the same or similar names are not binary equivalent. Binary differencing allows payload files to be adapted by the differential apply engine 230 to generate a version of the payload file that appears in the target archive 120. This adaptation unlocks all other schemes described herein, such as a region scheme for storing adapted files, a compression scheme, etc.

[0080] Now go to Figure 8 , various aspects of a routine for generating differences between archives using a common syntax are described and shown. For ease of understanding, the processes discussed in this disclosure are divided into separate operations represented as independent blocks. However, these separately divided operations should not be interpreted as necessarily having a sequential dependency in their execution. The order in which the processes are described is not intended to be interpreted as a limitation, and any number of the described process blocks may be combined in any order to implement the process or an alternative process. In addition, it is possible to modify or omit one or more of the provided operations.

[0081] refer to Figure 8 , method 800 begins at operation 802, where a target data block is replaced with a source data block having the same hash value.

[0082] Next, at operation 804, deltas are selected for generating payload files that are in both the source archive and the target archive but are not binary matched. The source archive and the target archive may be related by file name, identifier, path within the archive, or a combination thereof.

[0083] At operation 806, binary deltas are generated for the files identified in operation 804. One tool for generating binary deltas is BSDiff.

[0084] Next at operation 808 , it is determined whether the payload file is determined to be a sub-archive. If so, the method continues to operation 812 , where the entire differential tool chain is invoked on the sub-archive to generate a sub-difference archive, which can then be stored in the difference archive 140 .

[0085] Continuing to operation 810 , a manifest entry is added to the inline asset 450 of the difference archive 140 .

[0086] refer to Fig. 9 , the method 900 begins at operation 902, where a source scheme for generating a source payload file from a source data block is determined.

[0087] Next at operation 904, a target scheme for generating target data blocks from a target payload file is determined.

[0088] Next at operation 906, a delta scheme is determined that, when applied to the source payload file, produces a target payload file.

[0089] Next at operation 908, the target, delta, and source solutions are combined into a composite solution that can generate a target data block from the source data block.

[0090] Continuing to operation 910, the composite solution is stored in a differential archive.

[0091] The specific implementation of the disclosed technology herein depends on the performance of the computing device and other required selection matters. Therefore, the logical operations described herein are variously referred to as states, operations, structural devices, behaviors or modules. These states, operations, structural devices, behaviors and modules can be implemented in hardware, software, firmware, with dedicated digital logic and any combination thereof. It should be understood that more or less operations than those shown in the figure and described herein can be performed. These operations can also be performed in an order different from the order described herein.

[0092] It should also be understood that the method shown can be terminated at any time and does not need to be fully executed. Some or all of the operations of the method, and / or substantially equivalent operations, can be performed by executing computer-readable instructions included on a computer storage medium, as defined below. The term "computer-readable instructions" and its variants as used in the specification and claims are used broadly herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, etc. Computer-readable instructions can be implemented in various system configurations, including single-processor or multi-processor systems, minicomputers, mainframe computers, personal computers, handheld computing devices, microprocessor-based programmable consumer electronic devices, combinations thereof, and the like.

[0093] It should be understood, therefore, that the logical operations described herein are implemented: (1) as a sequence of computer-implemented behaviors or program modules running on a computer system; and / or (2) as interconnected machine logic circuits or circuit modules within a computer system. The implementation is a matter of choice depending on the performance and other requirements of the computing system. Thus, the logical operations described herein are variously referred to as states, operations, structural devices, behaviors, or modules. These operations, structural devices, behaviors, and modules may be implemented in software, in firmware, in dedicated digital logic, and any combination thereof.

[0094] For example, the operations of methods 500, 800, and 900 are described herein as being implemented at least in part by modules that run the features disclosed herein. These modules can be dynamically linked libraries (DLLs), statically linked libraries, functions generated by application programming interfaces (APIs), compilers, interpreters, scripts, or any other executable instruction sets. Data can be stored in data structures in one or more memory components. Data can be retrieved from a data structure by addressing a link or reference to the data structure.

[0095] Although the components of the reference diagram are shown below, it should be understood that the operation of methods 500, 800 and 900 can also be implemented in many other ways. For example, methods 500, 800 and 900 can be implemented at least in part by a processor or local circuit of another remote computer. In addition, one or more operations in the operation of methods 500, 800 and 900 can be alternatively or additionally implemented at least in part by a chipset that works alone or in combination with other software modules. In the example described below, one or more modules of the computing system can receive and / or process the data disclosed herein. Any service, circuit or application suitable for providing the technology disclosed herein can be used in the operation described herein.

[0096] Fig.10 Additional details are shown for an example computer architecture 1000 for a device, such as a computer or server configured as part of the systems described herein, that is capable of executing computer instructions (eg, modules or program components described herein). Fig.10 The computer architecture 1000 shown in the drawing includes (multiple) processing units 1002, a system memory 1004 (including random access memory 1006 (RAM) and read only memory (ROM) 1008), and a system bus 1010 that couples the memory 1004 to the processing unit(s) 1002.

[0097] Processing unit(s) (e.g., processing unit(s) 1002) may represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field programmable gate array (FPGA), another type of digital signal processor (DSP), or other hardware logic components that may be driven by a CPU in some cases. For example, illustrative types of hardware logic components that may be used include application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-chip (SOC) systems, complex programmable logic devices (CPLDs), and the like.

[0098] A basic input-output system, containing the basic routines that help to transfer information between elements within the computer architecture 1000 (e.g., during startup), is stored in the ROM 1008. The computer architecture 1000 also includes a mass storage device 1012 for storing an operating system 1014, application(s) 1016, modules 1018, and other data described herein.

[0099] The mass storage device 1012 is connected to the processing unit(s) 1002 through a mass storage controller connected to the bus 1010. The mass storage device 1012 and its associated computer readable media provide non-volatile storage for the computer architecture 1000. Although the description of computer readable media contained herein refers to a mass storage device, it should be understood by those skilled in the art that the computer readable media can be any available computer readable storage media or communication media that can be accessed by the computer architecture 1000.

[0100] Computer-readable media may include computer-readable storage media and / or communication media. Computer-readable storage media may include one or more of volatile memory, non-volatile memory, and / or other persistent and / or auxiliary computer storage media, removable and non-removable computer storage media, which are implemented in any method or technology for the storage of information, such as computer-readable instructions, data structures, program modules, or other data. Thus, computer storage media includes media in tangible and / or physical form included in the device and / or hardware components that are part of the device, as well as external to the device, including RAM, static random access memory (SRAM), dynamic random access memory (DRAM), phase change memory (PCM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, compact disk read-only memory (CD-ROM), digital versatile disk (DVD), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage devices, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network-attached storage devices, storage area networks, hosted computer storage devices, or any other storage memory, storage devices, and / or storage media that can be used to store and maintain information for access by a computing device.

[0101] In contrast to computer-readable storage media, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism. As defined herein, computer storage media does not include communication media. In other words, computer-readable storage media does not include communication media that consists solely of a modulated data signal, a carrier wave, or a propagating signal itself.

[0102] According to various configurations, the computer architecture 1000 can operate in a network environment using logical connections to remote computers through a network 1020. The computer architecture 1000 can be connected to the network 1020 through a network interface unit 1022 connected to the bus 1010. The computer architecture 1000 can also include an input / output controller 1024 for receiving and processing input from a number of other devices, including a keyboard, a mouse, a touch device, or an electronic stylus. Similarly, the input / output controller 1024 can provide output to a display screen, a printer, or other types of output devices.

[0103] It should be understood that the software components described herein, when loaded into (multiple) processing units 1002 and executed, can transform (multiple) processing units 1002 and the entire computer architecture 1000 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functions presented herein. The (multiple) processing units 1002 can be composed of any number of transistors or other discrete circuit elements, which can present any number of states individually or together. More specifically, the (multiple) processing units 1002 can operate as finite state machines in response to executable instructions contained in the software modules disclosed herein. These computer executable instructions can transform (multiple) processing units 1002 by specifying how (multiple) processing units 1002 are converted between states, thereby transforming the transistors or other discrete hardware elements that constitute (multiple) processing units 1002.

[0104] Fig.11 An exemplary distributed computing environment 1100 capable of executing the software components described herein is depicted. Fig.11 The distributed computing environment 1100 shown in the can be used to execute any aspects of the software components presented herein. For example, the distributed computing environment 1100 can be used to execute various aspects of the software components described herein.

[0105] Thus, the distributed computing environment 1100 may include a computing environment 1102 running on, communicating with, or being part of a network 1104. The network 1104 may include various access networks. One or more computing devices 1106A to 1106N may communicate with the computing environment 1102 via the network 1104. In one illustrated configuration, the computing devices 1106 include a computing device 1106A (e.g., a notebook computer, a desktop computer, or other computing device), a tablet computing device 1106B, a mobile computing device 1106C (e.g., a mobile phone, a smart phone, or other mobile computing device), a server computer 1106D, and / or other devices 1106N. It should be understood that any number of computing devices 1106 may communicate with the computing environment 1102.

[0106] In various examples, the computing environment 1102 includes a server 1108, a data storage device 1110, and one or more network interfaces 1112. The server 1108 can host various services, virtual machines, portals, and / or other resources. In the illustrated configuration, the server 1108 hosts a virtual machine 1114, a web portal 1116, a mailbox service 1118, a storage service 1120, and / or a social network service 1122. Fig.11As shown in , the server 1108 may also host other services, applications, portals, and / or other resources (“other resources”) 1124 .

[0107] As mentioned above, the computing environment 1102 may include a data store 1110. According to various implementations, the functionality of the data store 1110 is provided by one or more databases operating on or in communication with the network 1104. The functionality of the data store 1110 may also be provided by one or more servers configured to host data for the computing environment 1102. The data store 1110 may include, host, or provide one or more real or virtual data stores 1126A to 1126N (hereinafter collectively and / or broadly referred to as "data stores 1126"). The data store 1126 is configured to host data used or created by the server 1108 and / or other data. In other words, the data store 1126 may also host or store web documents, text documents, presentation documents, data structures, algorithms for execution by the recommendation engine, and / or other data utilized by any application. Various aspects of the data store 1126 may be associated with a service for storing files.

[0108] The computing environment 1102 can communicate with or be accessed by a network interface 1112. The network interface 1112 can include various types of network hardware and software to support communications between two or more computing devices (including computing devices and servers). It should be understood that the network interface 1112 can also be used to connect to other types of networks and / or computer systems.

[0109] It should be understood that the distributed computing environment 1100 described herein can provide any aspect of the software elements described herein, as well as any number of virtual computing resources and / or other distributed computing functions, which can be configured to perform any aspect of the software components disclosed herein. According to various implementations of the concepts and technologies disclosed herein, the distributed computing environment 1100 provides the software functions described herein as services to computing devices. It should be understood that the computing device can include real or virtual machines, including server computers, network servers, personal computers, mobile computing devices, smart phones and / or other devices. Therefore, various configurations of the concepts and technologies disclosed herein enable any device configured to access the distributed computing environment 1100 to utilize the functions described herein for providing the technologies disclosed herein, etc.

[0110] Although certain example embodiments have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the inventions disclosed herein. Therefore, nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, module, or block is necessary or indispensable. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The appended claims and their equivalents are intended to cover such forms or modifications that would fall within the scope and spirit of certain inventions of the inventions disclosed herein.

[0111] It should be understood that any reference to "first", "second", etc. elements in the Summary of the Invention and / or the Detailed Description is not intended to and should not be interpreted as necessarily corresponding to any reference to "first", "second", etc. elements in the claims. On the contrary, any use of "first" and "second" in the Summary of the Invention, the Detailed Description, and / or the claims can be used to distinguish two different instances of the same element.

[0112] The disclosure presented herein also includes the subject matter set forth in the following clauses:

[0113] Example 1: A method for generating a differential archive based on a source archive and a target archive, the method comprising: determining a source scheme for generating a source payload file from source data blocks of a source archive; determining a target scheme for generating a target data block from a target payload file of a target archive; determining a differential scheme that, when applied to the source payload file, generates the target payload file; combining the target scheme, the differential scheme, and the source scheme into a composite scheme that generates a copy of the target data block at least in part from a copy of the source data block; and storing the composite scheme in a differential archive, wherein the differential archive is applied together with data from the source archive copy to generate the target archive copy.

[0114] Example 2: The method according to Example 1 also includes: transmitting the differential archive to a computing device, wherein the computing device is able to have access to the source archive copy, and wherein the computing device applies the differential archive together with data from the source archive copy to generate a target archive copy.

[0115] Example 3: A method according to Example 1, wherein the source data block is one of multiple source data blocks stored in the source archive and can be used to extract the source payload file, and wherein the source scheme for generating the source payload file includes a connection scheme that connects multiple source data blocks into the source payload file.

[0116] Example 4: A method according to Example 1, wherein the target data block is one of multiple target data blocks stored in a target archive and available for extracting a target payload file, and wherein the target scheme includes a zone scheme that copies multiple target data blocks from the target payload file to individual offsets within the target payload file.

[0117] Example 5: A method according to Example 1, wherein the target scheme includes a target payload file parameter, which identifies a payload file of a target archive from which the target data block originates, and wherein the target scheme, the differential scheme and the source scheme are combined in part by replacing the target payload file parameter with the differential scheme.

[0118] Example 6: The method of example 5, wherein the delta solution includes source payload file parameters, and wherein the target solution, the delta solution, and the source solution are combined in part by replacing the source payload file parameters with the source solution.

[0119] Example 7: The method of Example 1 further includes: calculating a binary difference between a source payload file and a target payload file, wherein the difference scheme applies the binary difference to the source payload file to produce a copy of the target payload file.

[0120] Example 8: A method according to Example 6, wherein the source payload file parameters include a first source payload file parameter, and wherein the composite scheme also includes an intermediate scheme having a second source payload file parameter, the method further comprising: replacing the first source payload file parameter in the differential scheme with the intermediate scheme; and replacing the second source payload file parameter in the intermediate scheme with the source scheme.

[0121] Example 9: A method according to Example 8, wherein the intermediate scheme compresses the source payload file, decompresses the source payload file, encrypts the source payload file, decrypts the source payload file, combines the source payload file with other source payload files, or combines parts of the source payload file with other source payload files.

[0122] Example 10: A method according to Example 6, wherein the target payload file parameters include first target payload file parameters, and wherein the composite scheme also includes an intermediate scheme having a second target payload file parameter, the method further comprising: replacing the first target payload file parameter in the target scheme with the intermediate scheme; and replacing the second target payload file parameter in the intermediate scheme with the differential scheme.

[0123] Example 11: The method of Example 10, wherein the intermediate scheme decompresses, compresses, decrypts, or encrypts the output of the differential scheme.

[0124] Example 12: A computing device comprising: a processor; and a memory having computer executable instructions stored thereon, which, when executed by the processor, cause the computing device to perform operations comprising: determining a source scheme for generating a source payload file from a source data block of a source archive; determining a target scheme for generating a target data block from a target payload file of a target archive; determining a differential scheme that, when applied to the source payload file, produces the target payload file; combining the target scheme, the differential scheme, and the source scheme into a composite scheme that generates a copy of the target data block at least in part from a copy of the source data block; and storing the composite scheme in a differential archive, wherein the differential archive is applied together with data from the source archive copy to generate the target archive copy.

[0125] Example 13: The computing device of Example 12, wherein the computer-executable instructions further cause the computing device to: determine that the source payload file includes a sub-archive; wherein the source scheme recursively applies a method for generating a differential archive based on the sub-archive.

[0126] Example 14: A computing device according to Example 12, wherein the computer-executable instructions further cause the computing device to: generate a source archive metadata file comprising a first plurality of data block tokens, wherein the source data block is referenced by a data block token in the first plurality of data block tokens; and generate a target archive metadata file comprising a second plurality of data block tokens, wherein the target data block is referenced by a data block token in the second plurality of data block tokens, and wherein a single data block token comprises an archive offset, a length, and a hash value of the corresponding data block.

[0127] Example 15: A computing device according to Example 14, wherein the source archive metadata file includes a payload file token, which includes a file name of the source payload file and a scheme for generating a source payload file that references one or more data block tokens in the first plurality of data block tokens.

[0128] Example 16: A computing device according to Example 14, wherein the target archive metadata file includes a payload file token, which includes a file name of the target payload file and a scheme for generating one or more data block tokens of the second plurality of data block tokens from the target payload file.

[0129] Example 17: A computing device according to Example 14, wherein the source archive metadata file is generated by an archive reader specific to a particular archive type, and wherein the archive reader uses information specific to the particular archive type to open the source archive, identify data blocks, and generate the first plurality of data block tokens to refer to the identified data blocks.

[0130] Example 18: The method according to Example 14 also includes: analyzing the target archive and the second plurality of data chunk tokens to identify an area in the target archive that is not represented by any data chunk token in the second plurality of data chunk tokens; and adding a placeholder data chunk token to the second plurality of data chunk tokens that references the area of ​​the target archive.

[0131] Example 19: A system comprising: a processor; and a memory having computer executable instructions stored thereon, which instructions, when executed by the processor, cause the system to perform operations comprising: extracting a token comprising a block scheme from a differential archive, wherein the block scheme comprises references to data blocks stored in a source archive copy, and wherein extending the differential archive produces a payload file for a target archive; applying the block scheme to extract the data blocks from the source archive copy; extracting binary differences from the differential archive; and applying the binary differences to the data blocks extracted from the source archive copy to generate a payload file for the target archive.

[0132] Example 20: The system of Example 19, wherein the target archive is a subsequent version of the source archive.

[0133] Finally, although various techniques have been described in language specific to structural features and / or methodological acts, it will be understood that the subject matter defined in the attached description is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed subject matter.

Claims

1. A method for generating a differential archive based on a source archive and a target archive, the method comprising: determining a source scheme for generating a source payload file from source data chunks of the source archive; determining a target scheme for generating target data blocks from a target payload file of the target archive; determining a delta scheme, wherein the delta scheme, when applied to the source payload file, produces the target payload file; combining the target solution, the delta solution, and the source solution into a composite solution that generates, at least in part, a copy of the target data block from a copy of the source data block; as well as The composite schema is stored in the differential archive, wherein the differential archive is applied with data from a source archive copy to generate a target archive copy.

2. The method according to claim 1, further comprising: The differential archive is transmitted to a computing device, wherein the computing device has access to the source archive copy, and wherein the computing device applies the differential archive together with data from the source archive copy to generate the target archive copy.

3. The method of claim 1 , wherein the source data block is one of a plurality of source data blocks stored in the source archive and available for extracting the source payload file, and wherein the source scheme for generating the source payload file comprises a concatenation scheme that concatenates the plurality of source data blocks into the source payload file.

4. The method of claim 1 , wherein the target data block is one of a plurality of target data blocks stored within the target archive and available for extracting the target payload file, and wherein the target scheme comprises a zone scheme that copies the plurality of target data blocks from the target payload file to individual offsets within the target payload file.

5. The method of claim 1 , wherein the target scheme includes a target payload file parameter that identifies a payload file of the target archive from which the target data block originates, and wherein the target scheme, the delta scheme, and the source scheme are combined in part by replacing the target payload file parameter with the delta scheme.

6. The method of claim 5, wherein the delta solution includes source payload file parameters, and wherein the target solution, the delta solution, and the source solution are combined in part by replacing the source payload file parameters with the source solution.

7. The method according to claim 1, further comprising: A binary difference between the source payload file and the target payload file is calculated, wherein the differencing scheme applies the binary difference to the source payload file to produce a copy of the target payload file.

8. The method of claim 6, wherein the source payload file parameters include first source payload file parameters, and wherein the composite solution also includes an intermediate solution having second source payload file parameters, the method further comprising: replacing the first source payload file parameters in the differential solution with the intermediate solution; as well as The second source payload file parameters in the intermediate solution are replaced with the source solution.

9. The method of claim 6, wherein the target payload file parameters include first target payload file parameters, and wherein the composite solution also includes an intermediate solution having a second target payload file parameter, the method further comprising: replacing the first target payload file parameters in the target solution with the intermediate solution; as well as The second target payload file parameters in the intermediate solution are replaced with the delta solution.

10. A computing device comprising: processor; as well as a memory having stored thereon computer executable instructions that, when executed by the processor, cause the computing device to perform operations comprising: determining a source scheme for generating a source payload file from source data chunks of a source archive; determining a target scheme for generating target data blocks from a target payload file of a target archive; determining a delta solution that, when applied to the source payload file, produces the target payload file; combining the target solution, the delta solution, and the source solution into a composite solution that generates, at least in part, a copy of the target data block from a copy of the source data block; and The composite schema is stored in a differential archive, wherein the differential archive is applied with data from a source archive copy to generate a target archive copy.

11. The computing device of claim 10, wherein the computer executable instructions further cause the computing device to: determining that the source payload file includes a sub-archive; wherein the source scheme recursively applies the method for generating a differential archive based on the sub-archive.

12. The computing device of claim 10, wherein the computer executable instructions further cause the computing device to: generating a source archive metadata file comprising a first plurality of data chunk tokens, wherein the source data chunk is referenced by a data chunk token of the first plurality of data chunk tokens; and A target archive metadata file is generated comprising a second plurality of data chunk tokens, wherein the target data chunk is referenced by a data chunk token of the second plurality of data chunk tokens, and wherein an individual data chunk token comprises an archive offset, length, and hash value of the corresponding data chunk.

13. The computing device of claim 12, wherein the computer executable instructions further cause the computing device to: analyzing the target archive and the second plurality of data chunk tokens to identify regions of the target archive not represented by any data chunk token of the second plurality of data chunk tokens; and A placeholder data chunk token is added to the second plurality of data chunk tokens that reference the region in the target archive.

14. A system comprising: processor; as well as a memory having computer executable instructions stored thereon, which, when executed by the processor, cause the system to perform operations comprising: extracting a token including a chunk scheme from a differential archive, wherein the chunk scheme includes references to data chunks stored in a source archive copy, and wherein extending the differential archive produces a payload file of a target archive; applying the chunk scheme to extract the data chunks from the source archive copy; extracting binary differences from the difference archive; and The binary delta is applied to the data blocks extracted from the source archive copy to generate the payload file of the target archive.

15. The system of claim 14, wherein the target archive is a subsequent version of the source archive.

Images