{"id":2213,"date":"2006-05-19T16:47:00","date_gmt":"2006-05-19T16:47:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/heaths\/2006\/05\/19\/file-sequencing-and-how-files-are-located\/"},"modified":"2006-05-19T16:47:00","modified_gmt":"2006-05-19T16:47:00","slug":"file-sequencing-and-how-files-are-located","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/setup\/file-sequencing-and-how-files-are-located\/","title":{"rendered":"File Sequencing and How Files are Located"},"content":{"rendered":"

The\nFile\ntable<\/a> in a Windows Installer package has a Sequence column that begins with\n1. Besides determining in what order files are to be installed, this column\nserves another, relatively more important function: determining where the source\nfiles are located.<\/p>\n

In concert with the\n\nMedia table<\/a>, a range of sequence numbers identify in which cabinet – if that\nrange of files is even compressed – the files are located. The Media table has a\ncolumn named LastSequence that is inclusive of the maximum sequence number of a\nparticular file range. All files in the File table with a sequence number\ngreater than the previous Media table entry’s LastSequence and less than or\nequal to another Media table entry’s LastSequence are contained in the latter\nmedia. To put that a little more plainly, see the following color-coded\ntables.<\/p>\n\n\n\n\n\n\n
\n

File table (partial)<\/p>\n<\/caption>\n

File<\/font><\/th>\n…<\/font><\/th>\nFileName<\/font><\/th>\n…<\/font><\/th>\nAttributes<\/font><\/th>\nSequence<\/font><\/th>\n<\/tr>\n
A_DLL<\/td>\n…<\/td>\na.dll<\/td>\n…<\/td>\n0<\/td>\n1<\/td>\n<\/tr>\n
B_DLL<\/td>\n…<\/td>\nb.dll<\/td>\n…<\/td>\n0<\/td>\n2<\/td>\n<\/tr>\n
C_DLL<\/td>\n…<\/td>\nc.dll<\/td>\n…<\/td>\n16384<\/td>\n3<\/td>\n<\/tr>\n
D_DLL<\/td>\n…<\/td>\nd.dll<\/td>\n…<\/td>\n16384<\/td>\n4<\/td>\n<\/tr>\n<\/table>\n\n\n\n\n
\n

Media table<\/p>\n<\/caption>\n

DiskId<\/font><\/th>\nLastSequence<\/font><\/th>\nDiskPrompt<\/font><\/th>\nCabinet<\/font><\/th>\nVolumeLabel<\/font><\/th>\nSource<\/font><\/th>\n<\/tr>\n
1<\/td>\n2<\/td>\nDisk 1<\/td>\nAB.cab<\/td>\nDISK1<\/td>\n <\/td>\n<\/tr>\n
2<\/td>\n4<\/td>\nDisk 2<\/td>\n#CD.cab<\/td>\nDISK2<\/td>\n <\/td>\n<\/tr>\n<\/table>\n

The files a.dll<\/i> and b.dll<\/i> may<\/b> be compressed into AB.cab<\/i>,\nwhile c.dll<\/i> and d.dll<\/i> will be compressed into CD.cab<\/i>. \nCD.cab<\/i> begins with a hash symbol (#) because, as documented for the\nCabinet\ndata type<\/a>, that cabinet will be embedded as a stream within the .msi<\/i>\npackage. AB.cab<\/i> would identify a cabinet in the root of the source tree\nspecified in the\n\nDirectory table<\/a>.<\/p>\n

You might also notice that I said the files a.dll<\/i>\nand b.dll<\/i> may<\/b> be compressed into AB.cab<\/i> because, depending on the\nWord Count, those files aren’t explicitly attributed to be compressed.\n\nThe Word Count Summary Property<\/a> describes the default setting for whether\nfiles are compressed or uncompressed. As documented in\n\nCompressed and Uncompressed Sources<\/a>, the Attributes column values of the File table\noverride the Word Count property value. So, if the Word Count property\nspecified that all sources were compressed then files a.dll<\/i> and b.dll<\/i>\nwould be compressed into AB.cab<\/i>; otherwise, if the Word Count property\nspecified that all sources were uncompressed then only files c.dll<\/i> and \nd.dll<\/i> would be compressed into their respective cabinet.<\/p>\n

Now, for example, b.dll<\/i> needs to be patched. A patch must carry the\nnew copy (or binary delta patch) of b.dll<\/i> so it must change the file\nsequence of b.dll<\/i> to match up with a new entry in the Media table to be\nadded by one of the patch transforms for a particular product, as discussed in more detail in\nWhat’s in\na Patch<\/a>. The transform beginning with a hash symbol (#) would make the\nfollowing changes from the previous tables.<\/p>\n\n\n\n\n\n\n
\n

File table (partial)<\/p>\n<\/caption>\n

File<\/font><\/th>\n…<\/font><\/th>\nFileName<\/font><\/th>\n…<\/font><\/th>\nAttributes<\/font><\/th>\nSequence<\/font><\/th>\n<\/tr>\n
A_DLL<\/td>\n…<\/td>\na.dll<\/td>\n…<\/td>\n0<\/td>\n1<\/td>\n<\/tr>\n
C_DLL<\/td>\n…<\/td>\nc.dll<\/td>\n…<\/td>\n16384<\/td>\n3<\/td>\n<\/tr>\n
D_DLL<\/td>\n…<\/td>\nd.dll<\/td>\n…<\/td>\n16384<\/td>\n4<\/td>\n<\/tr>\n
B_DLL<\/td>\n…<\/td>\nb.dll<\/td>\n…<\/td>\n20480<\/td>\n5<\/td>\n<\/tr>\n<\/table>\n\n\n\n\n\n
\n

Media table<\/p>\n<\/caption>\n

DiskId<\/font><\/th>\nLastSequence<\/font><\/th>\nDiskPrompt<\/font><\/th>\nCabinet<\/font><\/th>\nVolumeLabel<\/font><\/th>\nSource<\/font><\/th>\n<\/tr>\n
1<\/td>\n2<\/td>\nDisk 1<\/td>\nAB.cab<\/td>\nDISK1<\/td>\n <\/td>\n<\/tr>\n
2<\/td>\n4<\/td>\nDisk 2<\/td>\n#CD.cab<\/td>\nDISK2<\/td>\n <\/td>\n<\/tr>\n
3<\/td>\n5<\/td>\n <\/td>\n#P1.cab<\/td>\n <\/td>\nMspSrc3<\/td>\n<\/tr>\n<\/table>\n\n\n\n
\n

PatchPackage table<\/p>\n<\/caption>\n

PatchId<\/font><\/th>\nMedia_<\/font><\/th>\n<\/tr>\n
{45F3433D-47C1-4AAF-9B4C-4FA759A02C0A}<\/td>\n3<\/td>\n<\/tr>\n<\/table>\n

Re-sequencing this file locates it in the the patch in the embedded stream\nnamed P1.cab<\/i>. The attributes are changed to msidbFileAttributesPatchAdded<\/code>\n(4096) + msidbFileAttributesCompressed<\/code> (16384), the latter of which\nto override whatever the default Word Count is set for the .msi<\/i> package\nbeing patched. The Word Count property value of the .msp<\/i> file is used to\nidentify the minimum version of Windows Installer required to install the patch\nand does not specify compression. Prior to Windows Installer 2.0 you had to\nguarauntee uniqueness of file sequence numbers for both the installer package\nfor all patches, but starting with Windows Installer 2.0 you need only ensure\nthat file sequences numbers are correct for a given package since Windows\nInstaller 2.0 and newer will automatically adjust file sequence number as\nnecessary.<\/p>\n

When the transforms are applied from a patch and the files are re-sequenced,\na reinstall of the affected features or all of the product is performed as\ndocumented in\nHow\nPatching Works<\/a>. The value in the Source column of the Media table for DiskId\n3 is used to identify the location of the .msp<\/i> file in order to locate\nthe embedded cabinet.<\/p>\n

Do note that the default schema of the File and Media tables allow for a\nmaximum of 32,767 files including all changes made by any applicable patches. In\nthe last set of tables, Windows Installer would view the product as now having 5\nfiles. The reason is that the column data type is only a 2-byte signed integer.\nFor more information about how to author a package with more initial files or to\nallow for many more patches, read\n\nAuthoring a Large Package<\/a>.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"

The File table 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 […]<\/p>\n","protected":false},"author":389,"featured_media":3843,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[17,20],"class_list":["post-2213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-essentials","tag-installation"],"acf":[],"blog_post_summary":"

The File table 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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/2213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/users\/389"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/comments?post=2213"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/2213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media\/3843"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media?parent=2213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/categories?post=2213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/tags?post=2213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}