Sometimes it is required to update content stored in a storage device. For example, if the content is a software (such as an executable file), it is sometimes required to upgrade the software. However, it should be noted that sometimes other types of content also require updates, such as text or data stored in a database etc. Hereinafter the term “old version” or “original version” refers to content before update, the term “new version” or “updated version” refers to the content after it was updated. An “update package”, sometimes referred to also as a “difference”, a “difference result” or a “delta”, includes data provided as input for an update process, wherein the update process updates the old version to the new version in accordance with the update package.
There are several ways known in the art for generating update packages and using them for updating versions. For example, U.S. Pat. No. 6,546,552 (“Difference extraction between two versions of data-tables containing intra-references”, published 2003) discloses a method for generating a compact difference result between an old program and a new program. Each program includes reference entries that contain references that refer to other entries in the program. According to the method of U.S. Pat. No. 6,546,552, the old program is scanned and for each reference entry the reference is replaced by a distinct label mark, whereby a modified old program is generated. In addition, according to U.S. Pat. No. 6,546,552, the new program is scanned and for each reference entry the reference is replaced by a distinct label mark, whereby a modified new program is generated. Thus, utilizing directly or indirectly the modified old program and modified new program, the difference result is generated.
WO 2004/114130 (“Method and system for updating versions of content stored in a storage device”, published 2004) discloses a system and method for generating a compact update package between an old version of content and a new version of content. The system of WO 2004/114130 includes a conversion element generator for generating a conversion element associated with the old version and new version. It also includes a modified version generator for generating a modified version, and an update package generator for generating the compact update package. The compact update package includes the conversion element and a modified delta based on the modified version and the new version.
WO 2005/003963 (“Method and system for updating versions of content stored in a storage device”, published 2005) discloses a system and method for updating versions of content stored in a storage device. The system of WO 2005/003963 includes an update module for obtaining a conversion element and a small delta. It also includes a converted old items generator for generating converted old items by applying the conversion element to items of an old version, a data entries generator for generating data entries based on the modified data entries and on the converted old item, and a new version generator for generating a new version of content by applying the commands and the data entries to the old version.
U.S. Pat. No. 6,832,373 (“System and method for updating and distributing information”, published 2004) discloses devices, systems and methods for updating digital information sequences that are comprised by software, devices, and data. In addition, these digital information sequences may be stored and used in various forms, including but not limited to files, memory locations, and/or embedded storage locations. Furthermore, the devices, systems, and methods described in U.S. Pat. No. 6,832,373 provide a developer skilled in the art with an ability to generate update information as needed and, additionally, allow users to proceed through a simplified update path, which is not error-prone, and may be performed more quickly than through the use of technologies existing when U.S. Pat. No. 6,832,373 was filed.
It is known to those versed in the art that content can be stored in a storage device, such as disk or memory, while some storage devices are organized in blocks. Blocks being part of the original version are referred to as “old blocks” or “original blocks”, while blocks being part of an updated version are referred to as “new blocks” or “updated blocks”. In addition, when updating an original version forming an updated version thereby, the updated version can sometimes use content previously stored in blocks of the original version. That is, the content of updated blocks is sometimes similar to content of original blocks.
Furthermore, available storage devices can have a limited space. Thus, while updating versions in a storage device it is sometimes preferred to store the new version in place of the old version, saving space thereby. Such an update process, where the new version occupies at least some of the space previously occupied by the old version, is referred to, in the art as “in-place update” or “updating in-place”.
It should be noted that an update process can process the blocks of the old version in an order which does not necessarily correspond to the sequential order of the blocks within the file. The order in accordance with which blocks of the old version are updated is referred to as an “update sequence” or “update order”.
One of the outcomes of in-place updating is that once storage blocks have been updated, the content of at least some of them being part of the original version (i.e., at least part of the original content), is potentially lost. Therefore, once the process of updating has started and after some original blocks are modified to hold updated content (the updated content being part of the updated version), the storage device can store content which is partly original and partly updated version.
In addition, it is known in the art that the old content is sometimes required for the update process, such as in a delta update method. Therefore, if the update process is interrupted through the course of its running, before the creation of the new version is completed and when the stored content (or stored version) is partly old version and partly new version, the in-place update process can not be repeated from start anymore.
In light of the above it is realized that in-place updating can be sensitive to interruptions. When the process of in-place updating tries to resume from the point where it was interrupted (the resume location), it requires information that allows calculation of the location of interruption. After locating the location of interruption the update process may also need to restore other information, which was available to the interrupted process at the time of interruption.
Currently in the art a record referred to hereinafter as “state record” is commonly used for storing results of calculations calculated before the interruption. The results together with the identification of the current updated block form a “state” of the in-place update process. For example, if the update package is compressed and it is being decompressed on-the-fly during the update process for reading just the necessary parts for updating each old block, and were the amount of data decompressed from the update package depends on old contents of updated blocks, than this amount can not be re-computed again once blocks were actually updated.
As mentioned already above, the process can not restart from its beginning. Therefore it might be that some of the data in the state record can not be re-computed even if the last updated record is known—it needs to be restored by other means. The common practice in the prior art is to maintain a state-record as mentioned above in a storage device accessible to the update process, and to update it periodically during the update process, to reflect its progress, an operation referred to hereinafter as “state recording”. Using state recording enables the resumption of an in-place update process by re-constructing the state of the process as it was at the last successful update operation, and to continue the process towards its completion.
In some cases, the information stored during state recording can not be part of the contents being updated and must be separated to another area of storage. State recording takes time since it involves read & write operations from and to the storage device. In some case, where the read & write operations of the storage device are allowed only for whole blocks, the time required for the whole process is doubled—for each updated block there is another block to update—the one holding the states recording.
It is also known to those versed in the art that in order to properly resume an interrupted in-place update process there may also be the need to handle a corrupted block which was the result of an interrupted storage write operation. It could be impossible to restore the information in that block, as the block's old content was modified and there may be no way to restore its old content just by examining the file's other blocks. This problem is resolved by the prior art by using a backup buffer where any block's new content is being stored there first and than copying its content to its target block to be updated (hereinafter referred as “update-first”) or alternatively, the old block is copied to a backup buffer and afterwards the new content is generated and stored in its target block (hereinafter referred as “backup-first”). This method is also known in the art as “2-phase commit” scheme.
Updating software of embedded devices such as mobile telephones is an example for an in-place update procedure. It is realized that storage of mobile telephones can be limited. For example, a mobile telephone can have enough storage to hold only one version of its software (also called firmware). Maintaining state-recording inside blocks of the firmware itself is clearly not practical since it would interfere heavily with the process of creating the software and therefore it must be stored in a separate area of storage. Updating mobile phone's firmware is a relatively slow process due to the speed of the storage devices used (Flash memory). During the update process the phone is inoperable, creating the need to minimize the time it takes.
There is a need in the art for faster and reliable updating procedures, allowing shorter interruptions in embedded devices operation during software update.