Staging Part 2 – Disk Space Optimization

“Disk space optimizations” is one of the key features of MSIX:

Disk space optimizations. With MSIX there is no duplication of files across apps and Windows manages the shared files across apps. The apps are still independent of each other so updates will not impact other apps that share the file.

But how does MSIX accomplish this?

Every .msix package includes an AppxBlockmap.xml, which lists all files in the package along with their corresponding hashes.

In Windows 8 – when MSIX was first introduced¹ – staging would extract every file from the package directly into a file within the package’s install location (also known as the package directory, or pkgdir).

Windows 8.1 introduced disk space optimization by enabling file sharing across installed packages via hardlinks.

When staging a package, Deployment examines each file to determine if an identical file already exists on the system and can be shared. If so, Deployment creates a hard link to the existing file – and voilà: no additional disk space is consumed.

If Deployment finds no matching file (or cannot safely share it), it creates a new file in the pkgdir.

How It Works

Conceptually, the mechanism is straightforward.

As Deployment stages each file in the package, it uses the hash recorded in AppxBlockmap.xml to efficiently search for an identical file in another staged package that may be reused via hard link.

Deployment never hard links some files, including:

• Files in unsigned packages. These have no trustable means to verify their content, thus precluding sharing.
• Files with a size of zero (aka 0-byte files). Hard linking these would create CPU overhead in some scenarios, for no gain.
• Files in packages installed with the DeveloperMode option. These allow write access (kind of the point) and thus subject to change at any time, precluding sharing.
• Files in packages declaring the inProcessMediaExtension capability. These have unusual ACL requirements precluding hard links.

If a file and package doesn’t meet one of these restrictions, Deployment searches packages on the system for a compatible match. This evaluation includes several criteria:

• Both files must produce the same hash
• Both files must reside on the same volume²
• The filesystem must support hard links
• The existing package must be signed³ (see above)
• The existing package must not be installed with the DeveloperMode option (see above)
• The existing package must not declare the inProcessMediaExtension capability (see ablove)
• The existing file’s package status must be usable (aka OK e.g. not Tampered or PackageOffline

If an existing file satisfies these conditions, Deployment creates a hard link. The new package’s file and the existing file each receive their own directory entry, but both reference the same set of on-disk blocks⁴.

If an error occurs while attempting to create the hard link, Deployment skips it and the search continues.

If Deployment finds no suitable match, it extracts the package’s content to a new file.

¹ MSIX was originally named APPX.

² Hardlinks can’t span volumes.

³ Deployment used to require comparable signing, e.g. files in Store-signed packages could only hardlink with files in Store-signed packages (informally referred to as “don’t cross the streams”). This rule was relaxed to ‘any validly signed package’ (not merely comparably signed) in a 25H2 update.

⁴ The files have identical FILE_ID_INFO.