Partner Filesystem Contents


This is an outline of the Partner filesystem.


The filesystem is intentionally designed to have a consistent layout across areas of control.

So, various directories in a path represent configurable variables, and we can reduce the size of our document by indicating where these variables occur and leave it to the reader to replace them with context-approprivate values.

We’ll use all caps to indicate these variables in the examples.


The config level is the zone of control used by update and by the config loader. It must be one of the following values:

  • provider
  • customer
  • hub
  • site
  • seat


Sections of the filesystem pertaining to specific mapsets are placed (quite reasonably we think) in subdirectories named after the mapset.

Mapset names can (and should) contain spaces, and should be capitalized by word (e.g. “My Favorite Mapset”). These names should be user-friendly, since they appear in various places in the Map Viewer user interface.


Sections of the filesystem pertaining to specific modules are placed in subdirectories named (wait for it...) after the module.

Module names cannot contain spaces, and should be capitalized by word (e.g. “HowIMetYourModule”).


The operating system, for operating-system-specific files such as native libraries or applications.


In the Update framework, sections of the filesystem are placed in packages that are separately packaged, compressed, and transferred.


This is the name of a third-party vendor, customer, or other organization that has ownerships of important files in the installation.



The archive/ directory is used to store backups, undo information, and other files that represent older versions of the installation in one way or another.

  • archive/vfs/
  • archive/publisher/
  • archive/backups/


The config/ directory contains everything in the system that customizes it for a given customer or installation.

It can contain these subdirectories, named after the config level:

  • config/provider/
  • config/customer/
  • config/hub/
  • config/site/
  • config/seat/


This subdirectory largely mirrors the top-level system/ directory.


This subdirectory largely mirrors the top-level os/ directory.


This subdirectory contains the configuration for a map space.

In theory, there can be more than one named map space. However, in current practice there is only ever one: Standard.

Also in current practice, CONFIG_LEVEL is almost always customer.

  • config/CONFIG_LEVEL/mapspaces/
  • config/CONFIG_LEVEL/mapspaces/Standard/actions/*.bsh
  • config/CONFIG_LEVEL/mapspaces/Standard/legends/*.xml
  • config/CONFIG_LEVEL/mapspaces/Standard/scripts/*.bsh


This subdirectory contains map set definitions, generally only for dynamic mapsets. Published mapsets instead live in the maps/ top-level directory.

  • config/CONFIG_LEVEL/mapsets/MAPSET/
  • config/CONFIG_LEVEL/mapsets/MAPSET/settings.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/legends/*.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/styles/polygon/*.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/styles/polyline/*.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/styles/point/*.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/styles/text/*.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/icons/*.png
  • config/CONFIG_LEVEL/mapsets/MAPSET/actions/*.groovy
  • config/CONFIG_LEVEL/mapsets/MAPSET/startup/*.groovy
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/frontends/
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/finds.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/labelling.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/transforms.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/datatypes.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/naming.xml
  • config/CONFIG_LEVEL/mapsets/MAPSET/translation/connectivity/*.groovy


Data is reserved for use by mapsets to store user data. It is not affected by Update; its contents should only be modified by mapset scripts. The standard convention that mapset data should go in a subdirectory named after the mapset, and module data should go in a subdirectory named after the module.

  • data/MAPSET/
  • data/MODULE/


Logs are very important, and get their own top-level directory. Previous runs are stored in logs/archive/, and system reports are stored in logs/reports/.

  • logs/partner.log
  • logs/error.log
  • logs/performance.csv
  • logs/update.log
  • logs/archive/
  • logs/reports/
  • logs/modules/MODULE/
  • logs/update-custodian.log (v5)
  • logs/update-primary.log (v5)
  • logs/update-workbench.log (v5)


The maps/ directory contains published map sets. These are also called “static” map sets. The subdirectories of maps/ are named after the map set name - for example “Background”.

See Published Rover Map Files for more details on this section.

  • maps/MAPSET/
  • maps/MAPSET/data/
  • maps/MAPSET/finds/
  • maps/MAPSET/graphictypes/
  • maps/MAPSET/connectivity/
  • maps/MAPSET/tiles/
  • maps/MAPSET/tiles/0/
  • maps/MAPSET/tiles/1/
  • maps/MAPSET/tiles/2/


The modules/ directory contains pluggable modules for the Partner platform. These are divided into subdirectories by config level, just like the config/ directory.

  • modules/CONFIG_LEVEL/MODULE/settings.xml
  • modules/CONFIG_LEVEL/MODULE/info/
  • modules/CONFIG_LEVEL/MODULE/resources/
  • modules/CONFIG_LEVEL/MODULE/system/
  • modules/CONFIG_LEVEL/MODULE/mapsets/
  • modules/CONFIG_LEVEL/MODULE/default/
  • modules/CONFIG_LEVEL/MODULE/workbench/


The os/ directory contains operating-system-specific files. There is a subdirectory for each supported operating system.

  • os/linux/
  • os/mac/
  • os/windows/

The directory structure in each of these subdirectories is the same.

  • os/OS/install/
  • os/OS/jars/
  • os/OS/jre/
  • os/OS/programs/
  • os/OS/tools/
  • os/OS/troubleshooting/
  • os/OS/lib/


The system/ directory contains the generic code, scripts, resources and configuration files shipped with the partner system. Everything generic, except operating system-specific files is here.

  • system/config/
  • system/config/apps/
  • system/config/gui/
  • system/config/job/
  • system/config/logging/
  • system/images/
  • system/images/splash/
  • system/jars/
  • system/hub/
  • system/hub/php/
  • system/hub/php/vfs/
  • system/hub/web/
  • system/hub/web/home/
  • system/hub/webstart/


The update/ directory contains data files and archives used by the installation and update process.

For example, info/InstallType.txt describes the installation’s role in the update hierarchy. The info/UpdateChain.txt file contains the last dates and sources of each propagation for each level in the hierarchy.

Packages consist of a checksum file (.checksum) and a compressed boxcar file (.boxcar.gz).

  • update/
  • update/info/
  • update/info/InstallType.txt
  • update/info/UpdateChain.txt
  • update/packages/PACKAGE.checksum
  • update/packages/PACKAGE.boxcar.gz


The temp/ directory is where caches and other temporary files are stored.

The temp/ directory is cleared out at the beginning of every run of the Partner platform, so don’t leave anything important there.

programs/ (v5)

The programs/ directory contains executable program launchers. These are OS-specific and updated whenever Update is run on that installation.

  • programs/
  • programs/Workbench.bat

extensions/ (v5)

The extensions/ directory contains third-party and customer extensions. These are isolated to make it easier ot troubleshoot issues

  • extensions/
  • extensions/VENDOR/
  • extensions/VENDOR/config/
  • extensions/VENDOR/modules/
  • extensions/VENDOR/os/

v3x/ (v3)

The v3x/ directory is a hold-over from the v3x version of the Field Designer. Jobs and similar important files are still stored there.

  • v3x/
  • v3x/FieldDesigner/
  • v3x/FieldDesigner/reports/
  • v3x/FieldDesigner/data/jobs/
  • v3x/Hub/config/partner/interfaces/
  • v3x/reports/
  • v3x/Hub/data/jobs/