Embodiments of the present invention relate to the field of updating software application programs on a computing device. In particular, embodiments of this invention relate to provide faster and more efficient updates by applying a patch to a reference state of a file cached on the computing device to update a current version of a file.
Changes, including updates, to a software application program due to bug fixes, required functionality, and the like are inevitable. For example, discovered security vulnerabilities in an application require immediate attention, with an update package distributed as quickly as possible. Even for users connected to the web via high-speed network connections and especially for those users with low bandwidth connections, update package download size is of critical importance. Currently, software vendors that wish to distribute updates to their applications either issue an entirely new application installation image or issue update packages. Common problems faced by vendors include distribution of updates that are too large for download, too difficult or time-consuming to create, or require access to the original install media when applied. For example, in some systems, laptop users have to be connected to the network to install some of the patches.
Further, with the ever-increasing frequency of software product updates and the continually improving ease of patch distributions and applications, a variety of prior patches may or may not have been previously applied to a particular user's computer or other computing device. Given the number of updates distributed for the application, users may be at different product plus update configuration states. Prior systems experience great difficulty in updating all these product and patch configurations. For example, if a software vendor has already released four patches for a particular product, a user's computer may have none, some, or all of the previously released patches when an installation application is applying a fifth patch to the user's computer. As such, software vendors increasingly find it difficult to correctly update a software application using patches.
Some previous systems use a patch server in combination with file compression technology to minimize download bandwidth. An update process searches the user's computer for possible file targets, which are then sent to the patch server to determine the most optimized payload for the update (e.g., to provide a dynamic payload customized to the user's computer). However, the requirements for maintaining this configuration are too much for the typical software vendor. Most software vendors do not have the infrastructure to maintain numerous reference files or manage large patch servers. Further, this previous method requires the user to be connected to a network during the patching operation because there is a need for communication with a patch server.
Accordingly, a system for targeting a patch to a selected prior version of the file to update a current version of the file is desired to address one or more of these and other disadvantages.
Embodiments of the invention enable application vendors to distribute smaller and more reliable changes, including updates, for their applications. In an embodiment, the invention distributes application updates optimized for both size and speed without requiring access to the original installation media. On a user's computing device, the invention receives a patch having one or more updates for a file. The patch only includes updates targeted to certain prior versions (e.g., baselines) of the file. As such, the patch size is reduced. The file to be updated has a current state representing a reference state (e.g., a prior version) with at least one update applied thereto. The invention identifies the reference state from the current state and selects one of the one or more of the updates from the patch as a function of the identified reference state. The selected update corresponds to the identified reference state. The invention applies the selected update to the identified reference state to update the file.
In one embodiment, an update includes compressed binary data representing a difference or delta between a prior version of the file (e.g., a reference file) and the desired, updated file. The compression produces an even greater reduction in update package size and thereby a reduction in the bandwidth required to download the update package. With the reference file available on the target computer, the invention synthesizes the desired, updated file to apply the update.
The invention enables simple and fast creation, maintenance, and application of updates. The updates may be applied without access to the original installation source. Further, the updates install reliably and correctly regardless of which updates have already been applied to the file. In one embodiment, a copy-on-write cache stores a copy of all files affected by an update. The copy-on-write cache also enables the rollback of any applied updates and allows application of updates without requiring access to the original source media.
The invention also simplifies the creation of patches since the patches only need to target specific reference states of the file rather than all prior states of the file.
According to one aspect of the invention, a method applies a patch to a file on a computing device. The method includes receiving a patch with one or more file changes. The method also includes determining, from the received patch, a file on a computing device to be changed by the received patch. The method also includes identifying a current state of the determined file on the computing device. The identified current state represents a reference state with at least one other file change applied thereto. The method also includes identifying the reference state of the file from the identified current state and selecting one of the one or more file changes from the received patch as a function of the identified reference state. The selected file change corresponds to the identified reference state. The method also includes applying the selected file change to the identified reference state to change the file.
According to another aspect of the invention, a method applies a patch to a file on a computing device. The patch includes one or more updates to the file. The method includes storing a current version of the file and a plurality of prior versions of the file. The plurality of prior versions has a logical order relative to each other and to the current version. Each of the one or more updates corresponds to one of the stored prior versions of the file. The method also includes identifying, as a function of the logical order of the plurality of prior versions, one of the stored prior versions of the file to be updated. The method also includes selecting one of the updates to apply to the file. The selected one of the updates corresponds to the identified prior version. The method also includes applying the selected update to the identified prior version of the file.
According to still another aspect of the invention, a method provides a patch to create a new version of a file. The method includes defining a file to have a plurality of primary versions and one or more secondary versions. The method also includes identifying each of the plurality of primary versions. The method also includes generating a plurality of updates. Applying each of the generated plurality of updates to each of the identified primary versions results in a new version of the file. The method also includes aggregating the generated updates to create a patch for the file and providing the created patch to an end user.
According to yet another aspect of the invention, one or more computer-readable media have computer-executable components for applying a patch to a file on a computing device. The components include a sequencing engine for receiving a patch. The patch has one or more file changes. The components also include a resource update evaluation engine for determining, from the received patch, a file on a computing device to be changed by the received patch. The resource update evaluation engine further identifies a current state of the determined file on the computing device. The identified current state represents a reference state with at least one other file change applied thereto. The resource update evaluation engine further identifies the reference state of the file from the identified current state. The components also include a payload engine for selecting one of the one or more file changes from the received patch as a function of the identified reference state. The selected file change corresponds to the identified reference state. The components also include a patch engine for applying the selected file change to the identified reference state to change the file.
According to another aspect of the invention, a system applies a patch. The system includes a memory area storing a current state of a file and a reference state of the file having file changes applied thereto. The memory area further stores a patch. The patch includes one or more file changes. The system also includes a processor that is configured to execute computer-executable instructions for determining, from the patch stored in the memory area, the file to be changed by the patch stored in the memory area, selecting one of the one or more patch changes from the stored patch as a function of the reference state stored in the memory area, and applying the selected patch change to the stored reference state to change the file. The selected patch change corresponds to the reference state stored in the memory area.
Alternatively, the invention may comprise various other methods and apparatuses.
Other features will be in part apparent and in part pointed out hereinafter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
In an embodiment, the invention includes a patching solution. In particular, the invention enables application vendors to easily create small and reliable changes, including updates, with static payloads that do not require access to the original installation media when applied to a computing device and are applicable to all previous product plus update configuration states. As shown in
In
As such, application vendors only target baselines of the application or file when building the payload for a patch. By only targeting baseline application versions, application vendors eliminate the burden of managing large collections of reference files and reference versions of files, as well as the burden of creating and testing patches that correctly target large numbers of reference versions of the files. The application vendors (e.g., via their patch installation programs) need only maintain one or more baseline versions of the files on the user's computer. In one embodiment, only the two most recent baselines are cached on the user's computer. Another embodiment of the invention caches a different number of different sets of baselines on the user's computer. The application vendors declare whether a patch includes a new baseline version of a file or represents a baseline version of the application (denoted as a minor update). Further, the application vendors may declare the product that is updated by the patch, the relative order of the patch with respect to other patches, the targeted files of the patch, and the patch payload file updates, for example, in metadata associated with the patch.
Another embodiment of the inventions allows for the possibility of creating updates that only target the released-to-manufacturing (RTM) version of the product or files. The application vendors may indicate this via additional metadata added to the patch. An installer engine looking at this metadata uses this knowledge to synthesize the desired versions of the file directly from the RTM version of the file instead of using subsequently released baselines.
An embodiment of the invention includes defining a file to have a plurality of primary versions and one or more secondary versions. The invention identifies each of the plurality of primary versions and generates a plurality of updates corresponding thereto. That is, each of the generated plurality of updates applies to each of the identified primary versions. The actual application of each of the generated plurality of updates to the corresponding primary version results in the same new version of the file. The invention further includes aggregating the generated updates to create a patch for the file and providing the created patch to an end user.
Caching the Baseline Versions
The invention maintains a per-product cache on each user machine. In one embodiment, the baseline cache provides full-file (e.g., the entire copy of the file) baselines for files that have been updated by patches. The cache includes the originally installed file versions and, in one example, may include one or more recent baseline versions (e.g., the last service pack version of the file in a logical order of versions). The cache helps to reduce the need to access the original installation media. The cache is maintained in a copy-on-write manner such that a file is only added to the cache when it is updated by a patch. In one embodiment, the invention devotes ten percent of total disk space to the cache. Further, the caching behavior may be controllable via policy. Alternative embodiments of the invention may cache a full-file version of the file for some baselines and store other baselines in the form of binary-delta information which can generate the baseline from another cached baseline stored as binary-delta or full-file. Yet another embodiment of the invention may cache some baselines in the form of binary-delta information based on the current machine state.
In one embodiment, the cache is organized as a directory structure organized according to product boundaries. The cache stores full-file versions of the product files. For example, there may be a subdirectory for each baseline (e.g., product version). The author of the patch specifies the baselines. An identity embedded with or otherwise associated with the patch indicates the baseline.
With one or more of the baselines stored on the user's computer, the invention processes the update payload to synthesize the new file correctly without requiring the original installation media because the needed baseline versions are already available in the cache on the user's computer.
Applying the Patch
Referring again to
However, the RTM version of the file may also serve as a reference state if necessary (e.g., the SP1 version of the file was deleted) or if the patch author so chooses. That is, with or without directly specifying the RTM version as a reference state, the RTM version is available for synthesizing the new file (e.g., QFE3). In this example, given that the reference state of SP1 is RTM, the QFE3 file in
Referring next to
In one embodiment, the identified reference state of the file is independent of an original installation state (e.g., the RTM version) of the file. In another embodiment, the synthesis of the updated file involves the application of one or more file changes from several patches (one file change per patch) to the identified reference state.
In general, an exemplary installation engine of the invention searches for a baseline stored in the baseline cache to which to apply the patch. The installation engine traverses from baseline to baseline ignoring intermediate QFEs. In particular, exemplary operation of the installation engine is illustrated in
The installation engine or other embodiment of the invention tracks all baselines for a product by storing the status in a table in memory. The table indicates which baseline is active and which baseline(s) are being cached. Another table in memory maps patches to the files affected by the patches. With this table, the installation engine may enumerate a listing of all active patches that affected a single file.
In
While
For example, the installation engine computes a checksum value for each of the files in the baseline cache. In one embodiment, files in the baseline cache are stored based upon a file table key. If a computed checksum value matches a checksum value for an update in the patch (e.g., in a header), the installation engine has located a baseline version in the cache and a corresponding update in the patch to apply thereto.
In one embodiment, the computed checksum value for each file is cached in the baseline cache to improve performance. In this manner, instead of having to recompute the checksum value every time the file in the cache is queried, a simple lookup in an index can be used to obtain the checksum value. Such an index saves a lot of time considering the expense incurred in computing the checksum (e.g., mapping the whole file into memory and then hashing it). In another embodiment, the checksum computation may be delayed during caching if the file was included as a full-file update. In this manner, the checksum computation cost only affects the patch that subsequently needs it.
In another exemplary embodiment of the invention, the installation engine may locate baseline versions of the file by querying commonly used file properties such as file version, file language, digital signature data, file manifest or other identifying attributes contained within or associated with the files. These attributes may also be cached to improve performance.
Referring next to
Referring next to
Sequencing engine 504 further computes a logical order of an applicable patch relative to other applicable patches to be or already applied to patch target machine. For example, sequencing engine 504 may compute the logical order of application by determining a portion of the software product of which the applicable patches are members and then arranging the patches according to their relative orderings within the portion. Sequencing engine 504 then provides the computed patch sequence (i.e., the logical order of patches) of applicable patches to the resource update evaluation engine 506.
The resource update evaluation engine 506 receives the computed sequence from the sequencing engine 504, resource update data from update resource manifests, and resource update manifests from the applied patch state/history/metadata store. The resource update evaluation engine 506 generates a computed resource update list identifying the resources to be updated. The payload engine 508 receives the computed resource update list from the resource update evaluation engine 506, payload data from the applied patch state/history/metadata store, cached baseline files from the baseline cache, and binary deltas (e.g., representing a compressed difference between files) and full-file updates from the update payload. The payload engine 508 manages the file updates in each patch payload to determine the appropriate deltas to apply. The payload engine 508 outputs a desired product state. The patch engine 510 receives the desired product state from the payload engine 508 and the current machine state from the user's computer. Therefore, the patch engine 510 may determine how to apply the applicable patches to the user's computer as a function of the desired product state, the current machine state, and the computed patch sequence. The patch engine 510 applies the resulting updates to the user's computer according to the computed patch sequence such that patch target machine achieves the desired product state. The patch engine 510 also adds patch state/metadata/history to the applied patch state/history/metadata store. The applied patch state/history/metadata store may be referred to as, or included with, a configuration memory area which stores the current state of the file, among other data. If no reference file (baseline version of a file or original installation version of a file) is found in the cache or on disk, the user will be prompted for the original installation media.
In one embodiment, the patches are “sticky” in that even if the file being patched is not present on the target machine, the patch will be stored and later applied to the file when the file becomes available.
Directed Acyclic Graph (DAG)
In one specific implementation, if the invention fails to locate a desired baseline version (or a baseline version resulting from the patch that was applied last in a logical order of patches) of the file to which to apply the patch, the invention builds a directed acyclic graph (DAG) using predictive heuristics to identify the baseline to update and to determine the updates to apply to the identified baseline. In one embodiment, the edges of the DAG are unweighted (i.e. the edges all have the same cost) and the vertices are file checksums. The file checksum information is obtained from the patch header for the binary patch. The direction is from old file checksum to new file checksum. Active vertices are determined from existing available full files. An active vertex may be the file currently in the target location or one of the files in the baseline cache. A single-destination shortest paths algorithm is used to determine which binary patches for the file are required. There is only one destination (e.g., the target file checksum) but the starting vertices are multiple given the baseline cache files and existing files. If no shortest path result could be obtained, the invention resorts to prompting the user for access to the original installation media to obtain the original installation release of the file.
While creating a DAG is time-consuming, the invention optimizes the process by first attempting to use a limited DAG which includes the last binary patch plus the RTM and service packs. The limited DAG includes a graph built using the last binary patch in the sequence. A checksum value serves as the destination vertex. The possible source vertices come from the old checksum values. The remainder of the DAG is built by identifying a list of minor update patches. For each minor update patch, the patch header corresponding to the file being updated is queried and its information is added to the DAG. The checksum for the RTM file is also used as a possible source vertex. The direction and edges of the graph are determined based upon the old checksum values and the new checksum value. A single destination shortest path algorithm is used to determine which set of patches in the smallest number of hops from baseline to baseline is needed to update the file.
If the limited DAG does not yield the desired information, a complete DAG is built which contains vertices for all available information including QFEs, full files, and the file in the target location.
The method for creating and utilizing payload updates according to the invention may be employed by any servicing technology. This method is applicable to both static and dynamic payload designs, but will more commonly be appropriate to static payload distribution. In one embodiment, the invention is implemented without an installation engine. The update package format includes a means for bundling targeting information of the update with the payload. The targeting information and payload need not be contained within the same physical store. An engine or similar mechanism processes the targeting information and payload and organizes the delta updates in the appropriate order for application. The engine determines the appropriate checkpoint starting point on a per file basis and then synthesizes the new file using the checkpoint plus checkpoint deltas.
Binary Delta Compression
In one embodiment, a tool is provided that enables application vendors to create updates that utilize binary deltas as the patch payload. Conventional “self-contained” update packages (e.g., containing the entirety of all of the new files in compressed form) range from 500 kilobytes (KB) or less to several megabytes (MB), while service packs can be 100 MB or more. This makes download size a significant issue for customers with slow network connections. While the invention is operable with such update packages, the combination of the invention with other compression technologies is within the scope of the invention.
For example, binary delta compression is a technique for compressing files that differs from conventional techniques for compressing files. Conventional data compression techniques for file delivery use a compressor that accepts one file as input and produces a single compact version of that file as output. A decompressor performs the inverse function, accepting the compact form as input and reconstructing the original file for output on the destination computer.
In contrast, for each file to be delivered, a binary delta compressor takes two files as input: the new file for delivery (Fnew) and a reference file (Fref) as shown in
DeltaCreator(Fref, Fnew)→DeltaF (1)
DeltaApplicator(Fref, DeltaF)→Fnew (2)
If the reference file and the new file are very similar, the size of the delta will be very small, generally much smaller than the file that results from simply compressing the new file conventionally. The size of the delta is proportional to the number of differences between the reference file and the new file. While a compression ratio for conventional compression of executable files might be approximately 3:1, the compression ratio for binary delta compression may be, for example, 10:1, 1,000:1, or even higher depending on the size of the original file and the number of differences. For example, if the code change is to fix a single buffer-overrun vulnerability, the delta may be as small as a few hundred bytes.
Because the reference file exists on the destination computer (e.g., a baseline version in the cache), only the compact delta file needs to be transmitted to the destination computer to construct the new file.
Exemplary Operating Environment
The computer 130 typically has at least some form of computer readable media. Computer readable media, which include both volatile and nonvolatile media, removable and non-removable media, may be any available medium that may be accessed by computer 130. By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by computer 130. Communication media typically 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 and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of any of the above are also included within the scope of computer readable media.
The system memory 134 includes computer storage media in the form of removable and/or non-removable, volatile and/or nonvolatile memory. In the illustrated embodiment, system memory 134 includes read only memory (ROM) 138 and random access memory (RAM) 140. A basic input/output system 142 (BIOS), containing the basic routines that help to transfer information between elements within computer 130, such as during start-up, is typically stored in ROM 138. RAM 140 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 132. By way of example, and not limitation,
The computer 130 may also include other removable/non-removable, volatile/nonvolatile computer storage media. For example,
The drives or other mass storage devices and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into computer 130 through input devices or user interface selection devices such as a keyboard 180 and a pointing device 182 (e.g., a mouse, trackball, pen, or touch pad). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to processing unit 132 through a user input interface 184 that is coupled to system bus 136, but may be connected by other interface and bus structures, such as a parallel port, game port, or a Universal Serial Bus (USB). A monitor 188 or other type of display device is also connected to system bus 136 via an interface, such as a video interface 190. In addition to the monitor 188, computers often include other peripheral output devices (not shown) such as a printer and speakers, which may be connected through an output peripheral interface (not shown).
The computer 130 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 194. The remote computer 194 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer 130. The logical connections depicted in
When used in a local area networking environment, computer 130 is connected to the LAN 196 through a network interface or adapter 186. When used in a wide area networking environment, computer 130 typically includes a modem 178 or other means for establishing communications over the WAN 198, such as the Internet. The modem 178, which may be internal or external, is connected to system bus 136 via the user input interface 184, or other appropriate mechanism. In a networked environment, program modules depicted relative to computer 130, or portions thereof, may be stored in a remote memory storage device (not shown). By way of example, and not limitation,
Generally, the data processors of computer 130 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described herein.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks. It is recognized, however, that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.
Although described in connection with an exemplary computing system environment, including computer 130, the invention is operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
An interface in the context of a software architecture includes a software module, component, code portion, or other sequence of computer-executable instructions. The interface includes, for example, a first module accessing a second module to perform computing tasks on behalf of the first module. The first and second modules include, in one example, application programming interfaces (APIs) such as provided by operating systems, component object model (COM) interfaces (e.g., for peer-to-peer application communication), and extensible markup language metadata interchange format (XMI) interfaces (e.g., for communication between web services).
The interface may be a tightly coupled, synchronous implementation such as in Java 2 Platform Enterprise Edition (J2EE), COM, or distributed COM (DCOM) examples. Alternatively or in addition, the interface may be a loosely coupled, asynchronous implementation such as in a web service (e.g., using the simple object access protocol). In general, the interface includes any combination of the following characteristics: tightly coupled, loosely coupled, synchronous, and asynchronous. Further, the interface may conform to a standard protocol, a proprietary protocol, or any combination of standard and proprietary protocols.
The interfaces described herein may all be part of a single interface or may be implemented as separate interfaces or any combination therein. The interfaces may execute locally or remotely to provide functionality. Further, the interfaces may include additional or less functionality than illustrated or described herein.
In operation, computer 130 executes computer-executable instructions such as those illustrated in
The following examples further illustrate the invention. In one example of the operation of the patching solution of the invention, a file example.dll has several possible configurations. In particular, the following updates have been disseminated for example.dll in this order: QFE1, SP1, QFE2, SP2, QFE3, SP3, QFE4, SP4, and QFE5. The SPs represent baseline versions. In this example, all of the patches except QFE5 have been applied to the product associated with example.dll making SP4 the current state of the file. The SP4 version of the file is stored in the target directory. Further for this example, the copy-on-write cache policy is to store the last baseline and the RTM version in the cache (or elsewhere on the user's computer), resulting in the storage on the user's computer of the RTM version in the cache and the SP4 version of the file in the target directory. As each patch targets the last two baselines in this example, the binary patch QFE5 targets SP3 and SP4. After QFE5 is applied, the SP4 version of the file is added to the baseline cache. As a result, three versions of the file exist on the user's computer: RTM in the cache, SP4 in the cache, and QFE5 in the target directory.
If the last patch applied to the file were QFE4, the installation engine would know that the SP3 version of the file is located in the cache. However, in this example, because the last patch applied to the file was SP4, the installation engine knows that the SP4 version of the file may be found in the target directory. The installation engine looks at the checksum (e.g., a cyclic redundancy check) for the file in the target directory. The checksum values are computed by the installation engine or pre-computed and stored in an index file to reduce patching time. Upon finding the SP4 version, the installation engine applies QFE5 to the SP4 version because the patch includes an update targeted to the SP4 version.
If the SP4 version of the file is missing, the installation engine will search the baseline cache and other applied minor update (baseline) patches for a baseline reference file in order to formulate a baseline chain of updates for the file. In this scenario, all applied patches used binary deltas; therefore the only possible sources for a reference baseline file are the RTM version in the RTM baseline cache and the RTM version on the original installation source media. The installation engine finds the RTM baseline file and uses that as the reference file starting point. Subsequent baseline deltas are applied (+SP1, +SP2, +SP3, and +SP4) and then the final delta is applied (+QFE5).
In another embodiment of the invention for the same scenario, the installation engine is unable to find either SP3 or SP4 in the target directory or the cache, so the installation engine builds a DAG. In one embodiment, a limited DAG for this example has vertices of RTM, SP1, SP2, SP3, SP4, and QFE5. Edges connect the following vertices:
RTM→SP1
RTM→SP2
SP1→SP2
SP1→SP3
SP2→SP3
SP2→SP4
SP3→SP4
SP3→QFE5
SP4→QFE5
A single destination shortest path algorithm finds the shortest patch which comprises three hops. Any one of the following routes is possible:
RTM→SP2→SP4→QFE5
RTM→SP1→SP3→QFE5
RTM→SP2 SP3→QFE5
The order of execution or performance of the methods illustrated and described herein is not essential, unless otherwise specified. That is, elements of the methods may be performed in any order, unless otherwise specified, and that the methods may include more or less elements than those disclosed herein. For example, it is contemplated that executing or performing a particular element before, contemporaneously with, or after another element is within the scope of the invention.
When introducing elements of the present invention or the embodiment(s) thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results attained.
As various changes could be made in the above constructions, products, and methods without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.