File Sequencing and How Files are Located



in a Windows Installer package has a Sequence column that begins with
1. Besides determining in what order files are to be installed, this column
serves another, relatively more important function: determining where the source
files are located.

In concert with the

Media table
, a range of sequence numbers identify in which cabinet – if that
range of files is even compressed – the files are located. The Media table has a
column named LastSequence that is inclusive of the maximum sequence number of a
particular file range. All files in the File table with a sequence number
greater than the previous Media table entry’s LastSequence and less than or
equal to another Media table entry’s LastSequence are contained in the latter
media. To put that a little more plainly, see the following color-coded

File table (partial)


Media table

12Disk 1AB.cabDISK1 
24Disk 2#CD.cabDISK2 

The files a.dll and b.dll may be compressed into,
while c.dll and d.dll will be compressed into
begins with a hash symbol (#) because, as documented for the
data type
, that cabinet will be embedded as a stream within the .msi
package. would identify a cabinet in the root of the source tree
specified in the

Directory table

You might also notice that I said the files a.dll
and b.dll may be compressed into because, depending on the
Word Count, those files aren’t explicitly attributed to be compressed.

The Word Count Summary Property
describes the default setting for whether
files are compressed or uncompressed. As documented in

Compressed and Uncompressed Sources
, the Attributes column values of the File table
override the Word Count property value. So, if the Word Count property
specified that all sources were compressed then files a.dll and b.dll
would be compressed into; otherwise, if the Word Count property
specified that all sources were uncompressed then only files c.dll and
would be compressed into their respective cabinet.

Now, for example, b.dll needs to be patched. A patch must carry the
new copy (or binary delta patch) of b.dll so it must change the file
sequence of b.dll to match up with a new entry in the Media table to be
added by one of the patch transforms for a particular product, as discussed in more detail in
What’s in
a Patch
. The transform beginning with a hash symbol (#) would make the
following changes from the previous tables.

File table (partial)


Media table

12Disk 1AB.cabDISK1 
24Disk 2#CD.cabDISK2 
35 MspSrc3

PatchPackage table


Re-sequencing this file locates it in the the patch in the embedded stream
named The attributes are changed to msidbFileAttributesPatchAdded
(4096) + msidbFileAttributesCompressed (16384), the latter of which
to override whatever the default Word Count is set for the .msi package
being patched. The Word Count property value of the .msp file is used to
identify the minimum version of Windows Installer required to install the patch
and does not specify compression. Prior to Windows Installer 2.0 you had to
guarauntee uniqueness of file sequence numbers for both the installer package
for all patches, but starting with Windows Installer 2.0 you need only ensure
that file sequences numbers are correct for a given package since Windows
Installer 2.0 and newer will automatically adjust file sequence number as

When the transforms are applied from a patch and the files are re-sequenced,
a reinstall of the affected features or all of the product is performed as
documented in
Patching Works
. The value in the Source column of the Media table for DiskId
3 is used to identify the location of the .msp file in order to locate
the embedded cabinet.

Do note that the default schema of the File and Media tables allow for a
maximum of 32,767 files including all changes made by any applicable patches. In
the last set of tables, Windows Installer would view the product as now having 5
files. The reason is that the column data type is only a 2-byte signed integer.
For more information about how to author a package with more initial files or to
allow for many more patches, read

Authoring a Large Package

Heath Stewart

Senior Software Engineer

Follow Heath   


Leave a comment