Many applications require the ability to write or modify data on the computer's filesystem and registry. When this need arises, ThinApp writes this data to the sandbox. This process is configurable and can be controlled through isolation modes.

The sandbox will store user settings so that these are preserved between application launches. If you delete the sandbox, the package will revert to its vanilla state. How big the sandbox will become depends on two factors: isolation modes and the behavior of the application.

The sandbox is a normal folder storing complete, fully functional versions of modified files. Let's say you run a virtualized application using .ini configuration files. Changing the application's configuration would alter the .ini file, and in your sandbox you would find the new version. It's fully functional and possible to open, for example, in native Notepad. The files are stored in folder macros, representing the path to the file. Since files are stored as native files and not in a binary blob, it's easy to perform backups of your sandbox. You can do single file restores and your antivirus software can scan its content without any problems.

The previous screenshot shows the sandbox contents stored as plain files in a path represented by a folder macro.

Modifications to the registry are also kept in the sandbox. In order to guarantee integrity, the registry is stored in a transactional database format. This makes it a little harder to investigate the contents of the registry changes stored in the sandbox, but with the tool called vregtool.exe found in the ThinApp utilities folder, it's still possible. It's important to maintain the integrity of the registry since the registry in the sandbox also includes a file database, telling the ThinApp runtime where to find each file.

The registry files are found in the root of the sandbox and are all called Registry.

The previous screenshot is an example of sandbox contents.

The database format for storing the registry was introduced in ThinApp Version 4.0.4. With DisableTransactionRegistry=1 in your Package.ini you can still use the legacy format, which uses a flat file with a backup of the last known good state. It's not very likely that you will want to use the legacy format, but in some rare implementations it has proven to speed up execution of the package, especially if the user's sandbox is stored on a network share.

The previous screenshot is a sandbox using the legacy method of storing the registry.

The sandbox can be located anywhere as long as the end user has permission to modify the location. The sandbox will be created and updated in the context of the user.

You can specify the location of the sandbox using the parameter SandboxPath= in Package.ini (more information about Package.ini can be found in the next chapter). If you do not specify SandboxPath=, the default location will be the user's roaming profile, in a folder called Thinstall. You can override the sandbox location using environment variables or by creating a folder called either the project's sandbox name or simply Thinstall in the same folder as the package.

You can use SandboxPath= in Package.ini in different ways.

The following is how you store the sandbox in a location next to the package:

[BuildOptions]
SandboxPath=.

This is shown in the following screenshot:

The following screenshot shows the result:

More examples are given as follows:

[BuildOptions]
SandboxPath=C:\Sandboxes

The following screenshot shows the result:

[BuildOptions]
SandboxPath=\\cnb\Sandboxes

The following screenshot shows the result:

Creating a folder called Thinstall next to the package will change the sandbox location. This comes in handy especially during troubleshooting. By using a Thinstall folder, you can override the content in your existing sandbox. The Thinstall folder is shown in the following screenshot:

Using environment variables to override a package sandbox location allows you to use the same package in many different environments. Let's say you want to store the sandbox in the default location on laptops, while you want to store them on a network share on your Terminal servers. Using an environment variable on your Terminal servers allows you to re-use the package without rebuilding it.

THINSTALL_SANDBOX_DIR overrides the sandbox location for all of your packages.

The environment variable %SandboxName_SANDBOX_DIR% redirects a specific package's sandbox location. Please note the variable value specifies the root of your sandbox folder.

ThinApp searches for the sandbox in a specific order. ThinApp starts by lookingfor the environment variable, %SandboxName_SANDBOX_DIR% followed by %THINSTALL_SANDBOX_DIR%. If no environment variable is found, ThinApp will look for the following folders and store the sandbox in the following locations:

If ThinApp fails to find %SandboxName_SANDBOX_DIR%, %THINSTALL_SANDBOX_DIR%, a Thinstall folder next to itself, or SandboxPath= in Package.ini, then ThinApp will create the sandbox in the default location, that is, in the user's roaming profile (%AppData%).

The search order for the sandbox in %AppData% is:

You can change the name of the sandbox. The default name will be taken from Inventory name specified during the capturing process, as shown in the following screenshot:

Using the parameter SandboxName= in Package.ini enables you to set the sandbox name.