Browse Prior Art Database

Incremental update technique for mirroring data from slow speed storage to fast access storage Disclosure Number: IPCOM000016193D
Original Publication Date: 2002-Aug-12
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



Disclosed is a software algorithm to solve the following problem A software application written in Java is commonly a set of class files which have been compressed and combined into Jar or Zip files. Jar/Zip files are more convenient for builders and installers as there are fewer files to manage, and are more convenient for customers as they take up less space. Even compressed, a large application set may require dozens of Jar/Zip files that each can be many megabytes. Usually these Jar/Zip files are stored locally when an application is installed, as local hard drive access time is much faster than if the program was stored on a LAN drive or brought over the network each time you needed to run it. Note that this disclosure is described in terms of a Java application example, however, the concepts could be used to update any arbitrary set of files with a master version of that file set. As another example, think of a master web server that wants to update copies of its web pages to a mirror web site. The problem is that if an application changes frequently, and the user wants or needs to have the latest Jar/Zip files installed locally, there can be frequent delays waiting for all the new files to be installed locally from some slower speed storage device such as a CD or LAN drive. With Java RMI applications the client code must be kept in sync with the server code, as this requirement is enforced by Java itself. Unmarshalling errors commonly occur when client code build date does not match the server code build date. The idea is to reduce the refresh delay by only updating a subset of each local Jar/Zip file. That is, only update any individual file contained in a Jar/Zip file if it has actually changed from the previous version. The problem is complicated by the fact that a Java build process can force all Java class file to be “built,” which updates the class file's last changed date, when in fact the resulting binary file is identical to the original class file.