App-V Volume Format Specification

Microsoft Application Virtualization Volume Format Specification
MICROSOFT APPLICATION VIRTUALIZATION VOLUME FORMAT SPECIFICATION

May 15 , 2010 - Version 1.0
th
Abstract
This specification describes the file format, internal structure and layout of volume files used by the Microsoft Application Virtualization (hereafter App-V) product.
1 Contents
2 3 Introduction ..................................................................................................................................... 2 Overview of App-V Volume File ........................................................................................................ 2 3.1 3.2 3.3 3.4 4 App-V Volume Format .............................................................................................................. 3 Container ................................................................................................................................. 4 Permanent First 16 Containers ................................................................................................. 9 Remaining containers after the first 16 ................................................................................... 20
Appendix ....................................................................................................................................... 31
Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to by accepting the license agreement.
2 INTRODUCTION
The reader should be familiar with the overall concept of application virtualization technology as well as concepts and terminology commonly used in conjunction with App-V. The following terminology is used in this paper: App-V Volume File The App-V volume file-system is a file based file-system that is all the data is stored in special volume files with any of the following file extensions: .fsd, .fsg, .pkg, and .tmp. Container A container is a data structure which contains some metadata about a data structure (i.e. directory structure, volume information, allocation map, file structure etc. Storage Block Storage Blocks serve as fixed size data containers which are marked as either used or free by the Storage Block Allocation Bitmap. Package A set of applications that have been sequenced by the App-V Sequencer. These applications share a common root and run under the same virtual environment.
3 OVERVIEW OF APP-V VOLUME FILE

The App-Vvolume file-system is a file based file-systemthat is all the data is stored in special volume fileswith any of the following file extensions: .fsd, .fsg, .pkg, and .tmp,rather than on the disk as individual files. A summary of each of the volume files is stated below: FSD Cache Volume (.fsd): This volume file maintains read-only package data which is basically the content of the SFT file. Thus FSD Cache Volume file acts as a true cache, where any data, if lost, can be fully recovered from the App-V Server. Global FSD Cache Volume (.fsg): This volume maintains any data that is created in the context of processes that are not registered within App-Vvirtual environment or are not related to any package. An example of such processes would be the App-VListener process, where it is not registered within App-V environment, but it is still allowed to access the App-Vfile system. Its contents are not recoverable if lost.While it is important to maintain the integrity of this volume, it has to be noted that if this volume is lost, it is not going to affect the streaming of the packages since this volume does not maintain any package specific data.
Per System Package Volume (.pkg/.tmp): There are 2 types of volumes in this case: one type maintainsany changes that were made to package specific files that are marked as APP_DATA/APP_CONFIG, and the other one maintains any changes that were made to package specific files that are marked as USER_DATA/USER_CONFIG. These changes are made by allowed system processes and by definition these are global to all users, and will affect all users logged on to the App-VClient. In multi-user environment all launches and shutdowns that occur on behalf of different users are maintained. These volumesare initialized when a user launches the first instance of the package, and will be closed, when the last instance of the package is closed. Per UserPackage Volume (.pkg/.tmp): Again there are 2 types of volumes in this case: one type maintains any changes that were made to package specific files that are marked as USER_DATA/USER_CONFIG, and the other one maintains any changes that were made to package specific files that are marked as APP_DATA/APP_CONFIG. Such changes are made by the applications of a specific package running under a user context. The USER_DATA Package Volume file will reside in user specific profile, and in roaming and folder-redirection profile environments it will be accessible to a user no matter what server user is logged on to. Theses volumes will be initialized when the user launches the first instance of the package, and will be closed, when the user closes the last instance of the package. For any volume other than FSD Cache Volume and Global FSD Cache Volume,while a volume is in-use we will be accessing its temporary copy (.tmp). The master copy will be updated only upon volume shutdown, which occurs when the last reference of the volume is closed. If any system failures occur while the volume is in-use that cause volume session shutdown or/and system reboot, the temporary copy of the volume will be discarded and any changes made to it will be lost. In case of FSD Cache Volume file, its contents will be analyzed upon reboot to determine if the previous abnormal shutdown could corrupt its contents, and if any or all data has to be discarded and re-fetched from the App-V Server.
3.1 APP-V VOLUME FORMAT

The volume files provide a persistent data storage for all the data that has to be used by App-V File System between system shutdowns and reboots. Since all these different types of volumes share the same format, from now on in the rest of the document they will be treated as a single type of volume. The root of a volume file is populated with several well-known Containers (explained in the next section)thattogether describe all the remaining data stored in a volume file. At the beginning, a volumefile is going to be divided into predetermined number of fixed size Storage Blocks, where a Block size is a configurable parameter. In present implementation, the default Storage Block size is 4 KB, and the default Container size is 512 bytes.Even though these 2 block sizes are configurable, it is advised not to change the default sizes which may produce undesired side effects in the File System. The number of Storage Blocks is determined by the size of the volume file, which is also a configurable parameter. Storage Blocks serve as fixed size data containers which are marked as either usedor free by the Storage Block Allocation Bitmap. The primary layout of a volume fileis shown in the figure 1:
Figure 1: Primary layout of an App-V volume In order to completely process an App-V volume, one needs to process all the containers and the data structures that the containers point to. Figure 2 shows a simple flowchart of a parser which enumerates the files and directories of a volume file:
Figure 2: Flowchart of a simple volume parser
3.2 CONTAINER
A container is a data structure which contains some metadata about a data structure (i.e. directory structure, volume information, allocation map, file structure etc.). So in order to process a data structure, we need to first process the container. The data structure that the container points to is either embedded within the container, or it is stored in a storage block outside the container block in which case the container will have some pointers to that storage block. The list of different type of containers is as follows: y y y y y Volume Container Primary: This container points to the volume information data structure which contains basic information about this volume. Volume Container Secondary: This container points to the duplicate volume information data structure used as a backup copy of the Volume Container Primary (unused). Container Allocation Map Container: This container points to the container allocation map structure. Security Descriptor Container: This container points to the security descriptor table. Storage Allocation Map Container: This container points to the storage allocation map data structure.
y y y y y y y y y
Reserved: This container is currently unused to be used in the future. Package Container: This container points to a package information data structure. Empty Container: This container is empty. It doesn t point to any valid data structure. Package Directory Container: This container points to a directory structure. This directory was created by App-V Sequencer and is part of a package. Run Directory Container: This container points to a directory structure which has been generated during the package runtime. Package File Container: This container points to a directory and file data block structure. This file was created by App-V Sequencer and is part of a package. Run File Container: This container points to a directory and file data block structure. This file has been created during the package runtime. Package Deleted Container: The corresponding file or directory has been marked as deleted. Link Data Container: The container points to a symbolic link.
Each container can logically be divided into two parts, where part one consists of a common header, and part two consists of an opaque data, the content of which is determined by the type of a container. By default the total size of a container is 512 bytes. The actual size of containers within a volume can be retrieved from the Volume Container Primary described later. Figure 2 depicts the common header of the Container structure:
Figure 3: Common Header of the Container Structure Common Header Field Descriptions The following provides detailed definitions of the fields used in a container common header:
TypeId This indicates the type of this container. The opaque data member of the container points to different data structures depending of this value. The following is the list of flags which are described in later sections:
Flag PACKAGE_FILE PACKAGE_DIRECTORY RUN_FILE RUN_DIRECTORY PACKAGE_DELETED SECURITY_DESCRIPTOR CONTAINER_EMPTY VOLUME_CONTAINER_P VOLUME_CONTAINER_S CONTAINER_RESERVED CONTAINER_PACKAGE LINK_DATA CONTAINER_ALLOCATION_MAP STORE_ALLOCATION_MAP TRANSACTION_LOG Value 0x00000001 0X00000002 0X00000003 0X00000004 0X00000005 0X00000007 0X00000008 0X00000009 0X0000000A 0X0000000B 0X0000000C 0X0000000D 0X0000000E 0X0000000F 0X00000010 Purpose Points to a package file data structure Points to a package directory data structure Points to a runtime generated file data structure Points to a runtime generated directory data structure Points to a file/directory which has been marked as deleted Points to the security descriptor table Empty container Points to the volume information data structure Duplicate copy of VOLUME_CONTAINER_P Reserved for future used (Unused) Points to a package information block Points to a symbolic link Points to the container allocation map structure Points to the storage allocation map structure Unused
Version This value identifies the particular version number of the data within this container. Thus, the Version number and container TypeId uniquely identify the specific format usage information for the container data. This number is unique to App-VFileSystem and is changed only when the format of the container is changed. GenerationId This value stores the version id of a file. It is specific to the files that are created as part of the package initialization. It is used during the package upgrade only to determine if a file has been changed and needs to be upgraded. PrimaryDirectoryId This indicates the parent directory container (the ContainerIndex of a container) where additional type specific information of this containeris located. For example, if a container points to a directory with ContainerIndex 30 and the parent directory of this directory has ContainerIndex 15, then PrimaryDirectoryId of this container will have value 15. A value of 0 implies that there is no parent associated with this container. FileGUID This value stores a unique file identifier (in GUID form). It is specific to files/directories that are created as part of package initialization, and used to find a specific Container by its GUID rather than by its name.
PackageID This indicates a package container(the ContainerIndex of a package container) that this file or directory (pointed to by this container) belongs to. A value of 0 implies that this container is not associated with any package. TypeName An ASCII type name buffer used for debugging purposes. InfoDataLength This describes the number of bytes used for the container type-specific information which is referenced by the Data member of the container (please see the container Data member section). CheckSum This is a checksum on the ContainerHdrwhich is an in-memory data structure. It does not cover data outside the container header and is present only to protect against certain types of runtime system failures. MetaDataIndex This is an offset into directory entrytable used for a quick lookup of the Container metadata structure within a parent container. (Please see the Root Directory section about the layout of a directory entry table). PackageDataIndex This is an offset into Package File Table used for a quick lookup of thecontainer reference within a package container (Please see the Package Container section about the layout of a directory entry table). ContainerIndex This is an index within the Container Table which is an in-memory data structure. For an on-disk Container structure, this value represents the sequence number that has been assigned to this container. This value is unique per container and used as a primary identifier. ContainerFlushIndex This is an index in volume file, where this container resides. It is used to locate/update on-disk container block. SecurityDescriptorIndex A security descriptor offset in the SecurityTable (Please see Security Descriptor Container for additional information). DataStorageType This indicates the format of the data storage region. The flags used are:
Flag FORMAT_RAW FORMAT_INLINE FORMAT_BLOCKMAP
Value 0x00000001 0X00000010 0X00000020
Purpose Raw data The data structure is inline within the container pointed to by the Data member The data structure is in a storage block outside of this container. The Data member points to the storage block containing the data.
A value of 0 in this field means Not Applicable (i.e. a container with TypeId CONTAINER_RESERVED). The format can be a bitmap of any of the following combinations (explained in a later section): FORMAT_RAW & FORMAT_BLOCKMAP FORMAT_RAW & FORMAT_INLINE Flags This is a bit mask of persistent flags that states additional information of the container:
Flag FILE_VERIFIED LOCKED NOTIFY_LAUNCH_DATA_REMOVED PACKAGE_FILE_MODIFIED PACKAGE_FILE ALLOC_MASK_DIRTY DATA_DIRTY MODIFIED_ACL_PERSISTED Value 0x00000001 0X00000002 0X00000008 0X00000010 0X00000020 0X00000040 0X00000080 0X00001000 Purpose The file data has been downloaded from the server and verified Used to lock the container while in use The package launch data has been deleted; the App-V Client needs to steam the data again from the Server Unused Package file Allocation map has been updated and needs to be flushed in the disk The container is updated and needs to be flushed The corresponding security descriptor (of the FSD Cache) has been updated and is now in the package volume file.
A value of 0 implies Not Applicable . SoftricityFileTypeFlags This is a bit mask of persistent flags that states additional information of the data structures pointed to by this container:
Flag FILETYPE_APP_DATA FILETYPE_APP_CONFIG FILETYPE_USER_DATA FILETYPE_USER_CONFIG FILETYPE_PERMANENT FILETYPE_OVERRIDE FILETYPE_DELETED Value 0x0001 0X0002 0X0004 0X0008 0X0010 0X0020 0X0040 Purpose Application data file (i.e. dll, exe etc.) Application configuration file User data file (i.e. txt file) User configuration file The corresponding file/directory cannot be deleted The corresponding file/directory can be overridden The corresponding file/directory has been deleted
A value of 0 implies Not Applicable . Data This member points to a data region within the container, the structure of which depends on the container TypeId. The data region can be further divided into 2 parts: Data Information Region, and
Data Storage Region. The container typespecific data information region is used to uniquely describe a structure the container points to. Its format is based upon the Container TypeId. Its size is defined by InfoDataLength value. After the data information region, datastorageregion takes up the remainder of the container buffer, and it begins immediately after the datainformation region. The DataStorageTypeand TypeId values of the container determine the content of DataStorageRegion.
3.3 PERMANENT FIRST 16 CONTAINERS

Volume Container Primary
This container contains information necessary to initialize the volume. The type of this container is VOLUME_CONTAINER_P. In addition to the common header, the container has the following volume specific information:
Figure 4: Volume Container Primary Data Information Region CSRInfo Structure: y VolumeVersion - Volume file version number y Flags - Stores one of the following flags:
Flag CSRINFO_DIRTY_STATE CSRINFO_ACTIVITY_STATE Value 0x00000001 0X00000002 0X00000000 Purpose The volume is in use. If the volume is closed but this flag is set then the volume has not been shut down properly. The volume has reference opened The volume is closed
CSRBlockSize - Size of a Container; Default is 512 bytes.
y y
STBlockSize - Size of a Storage Block, Default is 4096 bytes. FileSize The maximum size (in MB) that this volume can be grown without extending the storage allocation map.
Data Storage Region CSRDataStructure: y CreationTime - Time (UTC) when this volume is created. y VolumeLabelLength - Number of bytes in the VolumeLabelincluding the NULL double byte character. y VolumeLabel - Volume Name in WCHAR; Default is AppVirt . This is an array of fixed size 50 bytes.
Volume Container Secondary

This container is a duplicate of the Volume Container Primary to be used in the future for fail over of the Volume Container Primary.This container is of type VOLUME_CONTAINER_S.
ContainerAllocation MapContainer
Thiscontainer points to the ContainerAllocation Map structures. The TypeId of this container is CONTAINER_ALLOCATION_MAP. The ContainerAllocation Map is a permanent storage for a Container Bitmap that describes the layout of the CSR containers on-disk. The DataStorageTypeof this container should be a bitmap of FORMAT_RAW | FORMAT_BLOCKMAP.
Figure 5: Container Allocation Map Container Data Information Region

AllocMapInfo Structure: y BlockCount - Total number of Containers allocated for this volume y MapLen - Unused; currently set to 0. In order to completely decode an App-V volume, all the containers of the volume needs to be processed. The physical layout of all the containers of a volume is specified by one or more StorageBlockInfo which reside in the Data Storage Region of this container (Please see figure 6, 12 and 13 about how to process this bitmap and creating a container table). Data Storage Region This region contains one or more StorageBlockInfostructures which describe the starting storage index of a contiguous run of containers. If more containers are added to the volume, one or more StorageBlockInfostructures are added to this region. If this region is completely full with the StorageBlockInfo structures, a new storage block (4096 bytes default) will be assigned to hold the rest of the StorageBlockInfo structures. StorageBlockInfoStructure: y AllocationIndex - The start index of a contiguous run of Containers. y BlockCount - Indicates the number of CSR Containers referenced byAllocationIndex. There are 2 steps in processing the Container Allocation Map: 1. Process all the StorageBlockInfo structures. Figure 6 shows how to process all the StorageBlockInfo structures starting from the first one. Here initial it is assumed that the pointer points to the first StorageBlockInfo structure with in the container. 2. Each StorageBlockInfo structures points to a contiguous run of containers. Process all those containers for each of the StorageBlockInfo (Figure 12). In this step also build an in-memory Container Table (Figure 13).
Figure6: Flowchart of how to process all StorageBlockInfo of this container
Security Descriptor Container
This container points to an inline security descriptor table or a set of StorageBlockInfo structures which point to the storage blocks which contain the security descriptor table. The type of this container is SECURITY_DESCRIPTOR. This container has no Data Information Region so the InfoDataLength will be set to 0. If DataStorageTypeis true for FORMAT_BLOCKMAP flag, then right after the common header, there can be one or more StorageBlockInfostructures which point to the actual storage blocks that contain the security descriptors.If DataStorageType is true for FORMAT_INLINE flag, the security descriptors are within this container, right after the common header.
Figure 7: Security Descriptor Container (BlockMap format) Data Storage Region This region contains either StorageBlockInfostructures or _SECURITY_HDR structures with Windows NT security descriptors. _SECURITY_HDR Structure: y TypeId - Indicates whether this SD is in use or free. This value can be one of the following 2 flags:
Flag SECURITY_ENTRY SECURITY_EMPTY
Value 0x00000001 0X00000002 0X00000000
Purpose This is a valid SD A security entry was created before but is now empty in order to reuse the space The corresponding space is empty
y y y
EntryLength - Stores the total size of the SD including _SECURITY_HDR. DataLength - Stores the size of the SD. Data - Stores a reference to the beginning of the SD.
Figure 8: Security Descriptor Container (Inline format) For the purpose of linking directory entries (either directories or files) to the correct security descriptor entry, each directory entry contains an index which is a relative offset to a security descriptor entry. This index is an offset relative to the beginning of the Security Descriptor Table + 1. For example, the first security entry header starts at byte offset 0; the index (from a container) to it contains 1, and so forth, as illustrated below. If the SecurityDescriptorIndex of a container is 0, then the container doesn t have any corresponding security descriptor.
Security Descriptor Security Descriptor Security Descriptor

Securtiy Descriptors Subsection
Security Descriptor
...
Offset + 1
Directory Entry Directory Entry Directory Entry

Directory entries refer to security descriptors using relative offsets + 1
Figure 9: Security Descriptor mapping for a file or directory Ideally, the security descriptors should be contiguous from the beginning of the security descriptor table. However, because of the deletion and creation of the security descriptors, they become scattered throughout the security descriptor table. Hence, while decoding a volume, sometimes it becomes necessary to find a security descriptor by reverse mapping a container s SecurityDescriptorIndex into the security descriptor table and then extract the SD from the table.
Storage Allocation Map Container

This container points to the Storage Block Allocation Map bitmap where each bit describes whether a Storage Block is in use or free. It is not necessary to parse this structure if the volume is decoded only in the read-only mode. The type of this container is STORE_ALLOCATION_MAP. The structure of this container is same as that of Container Allocation Map Container with the following changes in interpretation of the AllocMapInfostructure: y BlockCount - Total number of Storage Blocks allocated to store the bitmap. y Maplen - Total size of the Bitmap in bytes. This bitmap can be represented in memory using RTL_BITMAPstructure.
Root Directory Container

The purpose of this container is to provide a permanent storage for the root directory of an App-V volume. It provides a starting point to enumerate an App-Vvolume. The name of this directory is always \ . The following is a depiction of the tree structure of the file system:
(Root)\ Office14.win7\ VFS\ VSTS2010.win7\ VFS\
The TypeIdof this container is PACKAGE_DIRECTORY. There is no Data Information Region for this container; that is the InfoDataLength field is set to 0. Based on the DataStorageType the container can have 2 different types of data storage region. If DataStorageTypeis true for FORMAT_BLOCKMAP flag, then right after the common header, there will be a _DIRECTORY_STRUCT_PRIMARY structure which describes the root directory. After the _DIRECTORY_STRUCT_PRIMARY structure there can be one or more StorageBlockInfo structures which point to the actual storage blocks that contain the rest of the _DIRECTORY_STRUCT_PRIMARY which are children to this directory.If DataStorageType is true for FORMAT_INLINE flag, any child _DIRECTORY_STRUCT_PRIMARY will be inline within this container after the root _DIRECTORY_STRUCT_PRIMARY.
Figure 10: Layout of Root Package Directory Container (Blockmap)
Figure 11: Layout of Root Package Directory Container (inline) Data Storage Region _DIRECTORY_STRUCT_PRIMARY Structure: This structure contains the metadata of a file or a directory. The structure consists of the following information: StructureTypeId This value indicates the type of the DirectoryPrimary structure. The value can be one of the following values:
Flag PACKAGE_FILE PACKAGE_DIRECTORY RUN_FILE RUN_DIRECTORY PACKAGE_DELETED
Value 0x00000001 0X00000002 0X00000003 0X00000004 0X00000005
Purpose Points to a package file data structure Points to a package directory data structure Points to a runtime generated file data structure Points to a runtime generated directory data structure The corresponding file or directory has been marked as deleted (This actually does not delete the actual file or directory rather hides the file or directory from directory enumeration) Empty container This structure points to a symbolic link. In this case we cannot use this structure any longer and we need to cast to _DIRECTORY_STRUCT_SECONDARY structure (described later)
CONTAINER_EMPTY LINK_DATA
0X00000008 0X0000000D
DirDataLen This is the total size of this structure. DirDataOffset -This is the offset of this structure entry within the parent directory entry table (the children directory structures that reside within a parent as depicted in the figure 10 and 11). ContainerIndex This is the index of the corresponding Container that describes this structure. OwnerId Security entity of the owner of this file or directory. Reserved Unused. CreationTime The time when the file/directory was created. ModificationTime The time when the file/directory was last modified. AccessTime The time when the file/directory was last accessed. AllocationLength - Current allocation length of this file. ValidDataLength This indicates the last byte written for the given file or directory; information beyond the Valid Data Length will read as zero values. For directory type, this value is always 0. SoftDataLength This indicates the actual size of the file s valid data length, as it is stored on App-VStreaming Server. PrimaryGroupId The security identifier of the primary group for the file/directory (this is principally for POSIX support, where the group ID is mandatory.) FileAttributes These are the standard Windows file attributes.
SoftricityFileTypeFlags Same as Container::SoftricityFileTypeFlags. ShortNameLength The length of the short file name (in bytes) not including the double byte terminating NULL character. FileNameLength The length of the long file name (in bytes) not including the double byte terminating NULL character. ShortName Short file name in WCHAR. This is an array of characters with fixed size 13 (26 bytes). FileName Long file name in WCHAR.
_DIRECTORY_STRUCT_SECONDARY Structure: This structure is only used if the structure type is LINK_DATA. This structure is just a shorter version of the _DIRECTORY_STRUCT_PRIMARY structure. The members are as follows: StructureTypeId DirDataLen DirDataOffset ContainerIndex PrimaryContainerId FileNameLength ShortNameLength ShortName FileName
Reserved Container
This container is of type SOFTFS_CONTAINER_RESERVED. All the data fields of this container are 0 except for the TypeId. Currently these containers are unused. Reserved containers should only reside in the volume from container flush index 5 to 14.
3.4 REMAINING CONTAINERS AFTER THE FIRST 16

After the first 16 containers, the rest of the containers need to be processed by decoding the Container Allocation Map. Figure 12 shows how to process containers following Container Allocation Map:
Figure 12: Processing containers following CSR Allocation Map. Figure 13 depicts a simple algorithmic view of processing of all the containers. In the figure we created a Container Table in memory in order to enumerate all the files and folders starting from root.
Container 0 (Volume Container Container 1 (Volume container backup Container 2 (CSR Allocation Map Container 15 (Root Container Container 16 (Varies, normally a package

Container n
Figure 13: A simple algorithmic view of processing all the containers
The different types of containers which can be processed by Container Allocation Map are described below:
Container type PACKAGE_DIRECTORY and RUN _DIRECTORY As stated in the earlier section, these 2 types of containers reference directories. The structure of this container is similar to Root Package Directory Container with one exception. This container does not have a fixed _DIRECTORY_STRUCT_PRIMARY structure which describes itself as seen in the case of Root Package Directory Container. Since the Root Package Directory Container does not have any parent, the Root Package Directory Container itself contains the _DIRECTORY_STRUCT_PRIMARY structure which contains the metadata of the root directory. For the rest of the directories, the _DIRECTORY_STRUCT_PRIMARY containing the metadata of the directories reside within the parent directory entry table.
Figure 14: Layout of a directory container when DataStorageType is blockmap
Figure 15: Layout of a directory container when DataStorageType is inline The following figure shows how to enumerate a volume starting from the root. Processing the data blocks of a file has been described in the later file container section.
Figure 16: Enumerating directories and files starting from root where the format of directory structure is INLINE
Container type CONTAINER_PACKAGE

The Package Container is used to track a set of files, directories, and other information specific to an App-V package. This container has both a Data Information Region and a Data Storage Region. Data Information Region Data Information Region within the Container referenced by Datamember contains the data of type _PACKAGE_INFOand InfoDataLengthmember of the container is initialized to the size of_PACKAGE_INFO. The structure _PACKAGE_INFO consists of the following information: PackageGUID A unique identifier of the package (GUID). AccessTime Indicates last time the package was accessed. PackageSize The sum of the sizes of all files that are part of the package. LaunchSize The actual size of the launch specific data required for the launch of the package. CachedFileSize The size of package file data resident in FSD Cache Volume File. CachedLaunchSize - The size of package launch specific file data resident in FSD Cache Volume File. PercentLaunch The percentage of the launch data cached. PercentTotal The percentage of the total data cached. PackVersion Indicates a version of this package; used during package upgrade. PackageName Name of the package. DirVersion Indicates a version of package metadata; used during package upgrade. PackVersionGUID - package version GUID; used during package upgrade. Rank Indicates package rank relative to other packages (Obsolete). MetaDataLength The length of the buffer that consists of metadata descriptors for all files and directories that belong to the package. SecurityDataLength - The length of the buffer that consists of security descriptors for all files and directories that belong to the package.
ServerBlockSize The size of the data storage block used by App-V streaming server. Reference Indicates how many instances of the package are opened. Flags Package specific flags; the value can be a bitmap of the of the following flags:
Flag PACKAGE_META_DATA_INITIALIZED PACKAGE_POPULATE_FAILED PACKAGE_NAME_COLLISION PACKAGE_PREALLOCATED
Value 0x00000001 0X00000002 0X00000004 0X00000008
VersionHistoryCount - Used during package upgrade. VersionHistoryBufferIndex - Used during package upgrade.
Figure 17: Layout of a package container Data Storage Regions Package Container maintains a Package Table that stores information about all files and directories that belong to the package or were created in context of the package. The Package Table is stored using a Block Map format. The Data Storage Region is used as a placeholder for Storage Block Table, where each entry in Storage Block Table is of type StorageBlockInfo, as described earlier. Last entry in Storage Block Table, if necessary, points to a next Storage Block, which is used as a placeholder for the next Storage Block Table. Each entry in a Storage Block Table points to a Storage Block that is used as a placeholder for Package File GuidTable. Each
entry in Package File GuidTable is of type _PACKAGE_FILE_GUID_INFO, where _PACKAGE_FILE_GUID_INFOstructure consists of the following members: FileGUID A unique identifier of the file/directory that belongs to the package. Index Index of the corresponding container of the package file/directory.
Container type RUN_FILE

Run-File container maintains a data index table which starts just after the container common header. Since there is no Data Information Region, the InfoDataLengthmember of the container is always set to 0. The format of the data index table (_SOFTFS_IND_FILE_BLOCK_ROOT_DATA) is as follows: FileDataTable - An array (size 20) of storage indexes (4 bytes each) that reference storage blocks that describe the first segment of the file, up to 80KB by default. IndirectionTableIndex - This is an index (4 bytes) to a storage block which contains an array of storage indexes (maximum 1024) that describe 2nd segment, up to 4MB. DblIndirectionTableIndex - This is an index (4 bytes) to a storage block which contains an array of storage indexes (up to 1024). Each of the indexes points to another storage block of data indexes which point to the actual data blocks. Using DblIndirectionTableIndex the maximum addressable data size is 4GB. TrplIndirectionTableIndex - This is another indirection layer on top of DblIndirectionTableIndexby which the maximum addressable data size is 4TB. In order to get the data of a file, we need to get each data index which points to an actual data block. Figure 18 portrays a file data layout and how to get the actual data blocks. For any volume other than FSD cache, if a data index contains 0, then the corresponding data block currently is not in this volume and we need to look at the corresponding data index table cell of FSD cache to get that data block. If the data index table cell of FSD cache is 0 then that data block is not in the cache and it must be streamed from App-V server into the FSD cache. Please note that Per User Package Volumes will only contain files of type SOFTFS_CONTAINER_RUN_FILE where as Per System Package Volumes can contain both SOFTFS_CONTAINER_RUN_FILE and SOFTFS_CONTAINER_PACKAGE _FILE types of files.
Data Block Index 1 Data Block Index 2 .. Data Block Index 20
Data Block Index 1
Data Block Index 1

Data Block Index 2
Data Block Index 2

..
.. Data Block Index 1023

Data Block Index 1023
Data Block Index 1

Data Block Index 1
Data Block Index 2 .. Data Block Index 1023
Data Block Index 1

Data Block Index 2
Data Block Index 2

..
.. Data Block Index 1023

Data Block Index 1023
Data Block Index 1 Data Block Index 2 .. Data Block Index 1023 Data Block Index 1 Data Block Index 2 .. Data Block Index 1023
Figure 18: Layout of a run file container
Container type SOFTFS_CONTAINER_PACKAGE_FILE

The format of this container is basically same as that of RUN_FILE container. The only difference between the two is that this container has a data information region which contains a PackageFileInfo (8 bytes) structure. The purpose of this structure is to store the reference of the storage block that maintains Feature Map Table type FeatureSetBlock. Basically it describes what feature data blocks that make up the file belong to. For example, feature block 1, 2, 3 ..., where feature block 1 is launch specific data. The structure has the following members: FeatureSetBlockIndex - Index of feature set (4 bytes) FeatureSetBlockCount - Stores the number of storage blocks allocated for FeatureSetBlock.(4 bytes) This structure is not needed in order to extract the data of a file.
Container type CONTAINER_EMPTY

This container was previously created but is no longer needed. In order to reuse it in the future it is marked as empty. It may or may not point to any valid data structure and will be reused when needed. This container should be ignored from processing.
4 APPENDIX
Special flags INVALID_VOLUME_ID INVALID_PACKAGE_ID INVALID_CSR_INDEX SOFTFS_END_OF_BLOCK 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF

App-V Volume Format Specification

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

App-V Volume Format Specification

Uploaded by

Copyright:

Available Formats

Microsoft Application Virtualization Volume Format Specification

MICROSOFT APPLICATION VIRTUALIZATION VOLUME FORMAT SPECIFICATION

Microsoft Application Virtualization Volume Format Specification

3 OVERVIEW OF APP-V VOLUME FILE

Microsoft Application Virtualization Volume Format Specification

3.1 APP-V VOLUME FORMAT

Microsoft Application Virtualization Volume Format Specification

Figure 2: Flowchart of a simple volume parser

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Flag FORMAT_RAW FORMAT_INLINE FORMAT_BLOCKMAP

Value 0x00000001 0X00000010 0X00000020

Microsoft Application Virtualization Volume Format Specification

3.3 PERMANENT FIRST 16 CONTAINERS

CSRBlockSize - Size of a Container; Default is 512 bytes.

Microsoft Application Virtualization Volume Format Specification

Volume Container Secondary

Figure 5: Container Allocation Map Container Data Information Region

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Figure6: Flowchart of how to process all StorageBlockInfo of this container

Security Descriptor Container

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Flag SECURITY_ENTRY SECURITY_EMPTY

Value 0x00000001 0X00000002 0X00000000

Microsoft Application Virtualization Volume Format Specification

Security Descriptor Security Descriptor Security Descriptor

Directory Entry Directory Entry Directory Entry

Storage Allocation Map Container

Root Directory Container

Microsoft Application Virtualization Volume Format Specification

(Root)\ Office14.win7\ VFS\ VSTS2010.win7\ VFS\

Microsoft Application Virtualization Volume Format Specification

Figure 10: Layout of Root Package Directory Container (Blockmap)

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Flag PACKAGE_FILE PACKAGE_DIRECTORY RUN_FILE RUN_DIRECTORY PACKAGE_DELETED

Value 0x00000001 0X00000002 0X00000003 0X00000004 0X00000005

Microsoft Application Virtualization Volume Format Specification

3.4 REMAINING CONTAINERS AFTER THE FIRST 16

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Figure 13: A simple algorithmic view of processing all the containers

Microsoft Application Virtualization Volume Format Specification

Figure 14: Layout of a directory container when DataStorageType is blockmap

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Container type CONTAINER_PACKAGE

Microsoft Application Virtualization Volume Format Specification

Flag PACKAGE_META_DATA_INITIALIZED PACKAGE_POPULATE_FAILED PACKAGE_NAME_COLLISION PACKAGE_PREALLOCATED

Value 0x00000001 0X00000002 0X00000004 0X00000008

Microsoft Application Virtualization Volume Format Specification

Microsoft Application Virtualization Volume Format Specification

Container type RUN_FILE

Microsoft Application Virtualization Volume Format Specification

Data Block Index 1 Data Block Index 2 .. Data Block Index 20

Data Block Index 1

Data Block Index 1

Data Block Index 2