Once the icepatch2server is running, you can use
icepatch2client to get a copy of the data directory that is maintained by the server. For example:
The client expects the data directory as its single command-line argument. As for the server, you must specify the
IcePatch2.Endpoints property so the client knows where to find the server.
If you have not run the client previously, it asks you whether you want to do a thorough patch. You must reply “yes” at this point (or run the client with the
‑t option—see
page 1633). The client then goes through the following steps:
When the client finishes, the contents of the data directory on the client side exactly match the contents of the data directory on the server side. However, only the uncompressed files are created on the client side—the server stores the compressed version of the files simply to avoid redundantly compressing a file every time it is retrieved by a client.
Once you have run the client, the client-side data directory contains an IcePatch2.sum file that reflects the contents of the data directory. If you run
icepatch2client a second time, the program uses the contents of the local checksum file: for each entry in the local checksum file, the client compares the local checksum with the server-side checksum; if the checksums differ, the client updates the corresponding file. In addition, the client deletes any files that exist only locally but not on the server side, and it fetches any new files that have been added to the server since the last time the client was run.
If you edit a client-side file and change its contents, the client does not realize that this has happened and patch the file to be in sync with the version on the server again. This is because the client normally does not recompute the checksum for a file to see whether the stored checksum in
IcePatch2.sum still agrees with the actual checksum for the current file contents.
If you have locally modified some files and want to make sure that those modified files are updated to reflect the contents of the same files on the server side, you must run a thorough patch with the
‑t option. Then the client first traverses the local data directory and recomputes the checksum for each file, and then compares these checksums against the server-side ones. This means that, if you edit a file locally so it differs from the server-side version,
‑t forces that file to be updated.
By default, the client deletes any files that exist in the local data directory but that are unknown to the server. If you do not want this behavior, you can set the
IcePatch2.Remove property to 0 (the default value is 1). This prevents deletion of files and directories that exist only on the client side.
Suppose you have a number of deployed clients that have been patched previously, and you want to distribute a new version of the application to these clients. To update the clients with the new version of the application, the clients can do a thorough patch. However, this is expensive if the pre-existing file set on the client side is large, because a thorough patch recompresses all files to compute the checksums.
As an alternative, you can place all the files for the distribution into a directory and run
icepatch2calc ‑Z on that directory. With the
‑Z option,
icepatch2calc creates a checksum file with the correct checksum, but with a file size of 0 for each file, that is, the
‑Z option omits compressing the files. Once you have created the new
IcePatch2.sum file in this way, you can distribute it to clients which then can use it to patch their distribution without having to do a thorough patch. For large file sets, this can result in considerable time savings.
You can set the IcePatch2.ChunkSize property to control the number of bytes that the client fetches per request. The default value is 100 kilobytes.
