Patch Packages

A Windows Installer patch (.msp file) is a file used to deliver updates to Windows Installer applications. The patch is a self-contained package that contains all the information required to update the application. A patch package (.msp file) can be much smaller than the Windows Installer package (.msi file) for the entire updated application. For more information about delivering smaller updates to applications, see Reducing Patch Size.

A patch package contains the actual updates to the application and describes which versions of the application can receive the patch. Patches contain at minimum two database transforms. One transform updates the information in the installation database of the application. The other transform adds information that the installer uses for patching files. The installer uses the information provided by the transforms to apply patch files that are stored in the cabinet file stream of the patch package. A patch package does not have a database like an installation package (.msi file.)

Beginning with Windows Installer version 3.0, patch packages can contain information that describe the patching sequence for the patch relative to other updates in the MsiPatchSequence table and additional descriptive information in the MsiPatchMetadata table.

Users can install applications and updates from a network administrative image. Although patch packages can be applied to administrative installations, the recommended method to deliver updates is to have users install the original application and then apply the patches to the local instance of the application on to their computer. This keeps users in synchronization with the administrative image. If a patch is applied to the administrative installation, all clients of that administrative installation must recache and reinstall the application to receive the update. Until a user recaches and reinstalls, the user is unable to install-on-demand and repair installations from the patched administrative installation.

Beginning with Windows Installer 3.0, non-administrators can apply patches to per-user-managed applications after the patch has been approved as trusted by an administrator. For more information on how to do this, see Patching Per-User Managed Applications. Another method is to use least privileged user account patching.

If the AllowLockdownPatch policy has been set, non-administrator users can apply a patch to an existing application while running an installation at elevated privileges. This method is not recommended because it enables untrusted patches to be applied to an application that can run with elevated privileges.

Patch packages are comprised of the following parts. For more information about the construction of patch packages, see Creating a Patch Package.

Summary Information Stream

The summary information stream of the patch package provides information about the identity and purpose of the patch.

The summary information stream holds a minimum of the following:

• A GUID that uniquely identifies the patch. The GUID for this patch is appended with a list of GUIDs for earlier patches that are replaced by this patch.
• A semicolon-delimited list of product codes for valid targets for this patch.
• A semicolon-delimited list of transform substorage names in the order they are to be processed.
• A semicolon-delimited list of sources for this patch.

Transform Substorage

A patch package contains transforms that can add or remove files, registry entries, user interfaces, and customizations. Transforms are included as substorages in the package. A patch package contains two transforms for each target database. One transform is the actual updates to the installation database and is generated from the differences between the original and updated images of the installation package. The other transform adds entries to the Patch, PatchPackage, Media, InstallExecuteSequence, and AdminExecuteSequence tables. Information in the substorage ties it to a specific UpgradeCode, ProductCode, ProductVersion, and ProductLanguage. A patch package that can be applied to multiple targets contains more than one pair of these transforms.

Cabinet File Stream

The cabinet file stream included in a patch can contain these types of files:

• Patch files containing the information required to change the old version of the file into the new version. A single patch file can be used to update one or more old versions of a file.
• Additional files being added to the application that are not present in the old version.
• An entire replacement file. In the rare case where the new version of a file is smaller than the patch required to update the old version of that file, the new file can be included in its entirety. These are new files that are installed over their old versions.

Patching

An application that has been installed using the Microsoft Windows Installer can be upgraded by reinstalling an updated installation package (.msi file), or by applying a Windows Installer patch (an .msp file) to the application.

A Windows Installer patch (.msp file) is a self-contained package that contains the updates to the application and describes which versions of the application can receive the patch. Patches contain at a minimum, two database transforms and can contain patch files that are stored in the cabinet file stream of the patch package. For more information about the parts of a Windows Installer patch package, see Patch Packages.

Servicing applications by delivering a Windows Installer patch, rather than a complete installation package for the updated product can have advantages. A patch can contain an entire file or only the file bits necessary to update part of the file. This can enable the user to download an upgrade patch that is much smaller than the installation package for the entire product. An update using a patch can preserve a user customization of the application through the upgrade.

**Windows Installer 4.5 and later:В В **

Beginning with Windows Installer 4.5, developers can mark components in a patch with the msidbComponentAttributesUninstallOnSupersedence value in the Component table. If a subsequent patch is installed, marked with the msidbPatchSequenceSupersedeEarlier value in its MsiPatchSequence table to supersede the first patch, Windows Installer 4.5 and later can unregister and uninstall components marked msidbComponentAttributesUninstallOnSupersedence to prevent leaving behind unused components on the computer. If the component is not marked with with this bit, installation of the superseding patch can leave an unused component on the computer. Setting the MSIUNINSTALLSUPERSEDEDCOMPONENTS property has the same effect as setting this bit for all components.

**Windows Installer 3.0 and later:В В **

Developers who use Windows Installer 3.0, and author patch packages that have the MsiPatchSequence table can create patch packages that do the following:

• Use the product baseline cached by the installer to more easily service applications with smaller delta patches. For more information about using the product baseline, see Reducing Patch Size.
• Skip actions associated with specific tables that are unmodified by the patch. This can significantly reduce the time required to install the patch. For more information about which tables can be skipped, see Patch Optimization.
• Create and install patches that can be uninstalled singly, and in any order, without having to uninstall and reinstall the entire application and other patches. For more information about uninstalling patches, see Removing Patches.
• Apply patches in a constant order regardless of the order that the patches are provided to the system. For more information about how the Windows Installer determines the sequence used to apply patches, see Sequencing Patches.
• Apply patches to an application that has been installed in a per-user-managed context. For more information, see Patching Per-User Managed Applications.

**Windows Installer 2.0:В В **

The MsiPatchSequence table is not supported. Beginning with Windows Installer 3.0, patch packages can contain information that describes the patching sequence for the patch relative to other updates and additional descriptive information.

The recommended method for creating a patch package is to use patch creation tools such as Msimsp.exe and Patchwiz.dll. Developers can generate a patch creation file as described in the section: Creating a Patch Package. The creation of a small update patch is described in the section: A Small Update Patching Example.

Microsoft Windows Installer accepts a Uniform Resource Locator (URL) as a valid source for a patch. For more information about how to install a patch located on a Web server, see Downloading and Installing a Patch From the Internet.

A single Windows Installer patch (.msp file) can be applied to the installation package when installing an application for the first time. For more information, see Patching Initial Installations.

It is not possible to eliminate all circumstances when the application of a patch may require access to the original installation source. However, to minimize the possibility that your patch will require access to the original source, adhere to the points listed in the following section: Preventing a Patch from Requiring Access to the Original Installation Source.

To minimize the possibility that your patch is not broken by a subsequent customization transform, typically the patch is installed first, followed by the customization. Installing customization transforms first, and then the patch, may break the customization. For more information about patching customized applications, see Patching Customized Applications.

How to apply a patch

Contents

Introduction

This page explains how you can apply a patch file. Patch is a standard format, and there are many options for how to apply one. Pick the one that is easiest for you.

Perhaps most critical is the usage of the -p flag, which tells patch about the relationship between the directory where the patch file is located and the files that will be patched. See the references below for details and DO NOT assume anything.

Apply a Patch in Windows using gnuwin32

• Download and extract patch for windows from sourceforge I placed the patch.exe binary in C:\bin (NOTE: Things are a lot easier if you put it in a directory that doesn’t have white spaces in it.)

• Download and extract Moodle somewhere. eg: C:\moodle

• Download the patch file and place it in the same directory you put Moodle (C:\moodle\password-policy-17.diff)

• Open the patch file with Wordpad, and click ‘File’ >> ‘Save as. ‘, choose a different name for the file eg (‘mynewpatch.diff’) and «Save as type» >> ‘Text Document — MS-DOS Format’

• Open up a command text window, and type:

The number after '-p' option can vary depending on the patch file, as it depends on the way the patch file was generated. Have a look at the ‘patch’ utility manual page to see how the '-p' option works. You could also have a look at this diff and patch tutorial.

• You should get an output similar to this (the names and quantity of patched files vary from patch to patch):

At this stage the patch has not been applied. We just simulated the application (with the '--dry-run' option), to see if we are going to find any problems with it. Before explaining how to actually apply the patch, we are going to talk about what could be wrong, and how to deal with it.

Potential problems and how to deal with them

Potential problems

If everything goes well, the patch will apply cleanly and life should be good! But sometimes the patch will not apply 100% cleanly due to a version mismatch between the original files used to produce the patch file and your local files. In this case, the ‘patch’ command will try to apply as many changes as it can, and will emit some diagnostics describing the problems it encounters.

• If you get any 'Hunk #n succeeded. ' messages, the patch would have been applied correctly although at different line numbers than the original file. If we had actually applied the patch, the ‘patch’ command would have created an additional file for each of the files where the hunk was applied at a different offset, that would be named like the original file with the additional extension .orig.

• If you get any 'Hunk #n failed. ' messages, the patch would have not applied correctly. In this case the ‘patch’ command would have created two additional files for each of the files where the hunk was not applied correctly, called:
  • original-file-name.orig This would be the original file before the patch was applied, just like above.
  • original-file-name.rej This file would contain the hunks that could not be applied correctly, so you could inspect them.

Dealing with potential problems

Dealing with the first problem (the offsetted hunks) is trivial: we just need to delete the .orig files once we actually apply the patch.

In the second case (failed hunks), unless you know how to fix the failed hunks by hand, you should not apply the patch, as that would corrupt your Moodle install. If you want to apply the patch and try to fix the failed hunks by hand, you should use the '-b' option. That option automatically makes a backup of every file the patch applies to, with the .orig extension. That would allow you go back to the original files state by simply overwritting the modified files with their .orig backups.

Sometimes, there will be a large difference in line numbers since a patch was generated and the patch will not apply. You can tell patch allow larger differences in line numbers by using the fuzz option ‘-F’ to increase the number of lines difference there can be. For example patch -F 100 would allow 100 lines difference.

Actually applying the patch

Now that we know what could go wrong and how to deal with it, let’s see how to apply the patch. We only need to remove the '--dry-run':

and optionally use the '-b' option if we are going to try to fix the failed hunks by hand:

Apply a Patch in Windows using NetBeans

NetBeans comes with integrated tools for version control and developer collaboration which include powerful graphical Diff tools and easily applying (and creating) patches. You can apply any patch to file from the file’s context menu.

Apply a Patch in Linux using «patch»

Put the patch file in the base directory of Moodle.

run in command line as root, (or su the command.) patch -p1 See Also