LiveCycle ES: explanation of GDS directories


The global document storage (GDS) in LiveCycle ES is a directory used to store long-lived files such as PDF files used within a process or DSC deployment archives. Long-lived files are a critical part of the overall state of the LiveCycle ES environment. If some or all long-lived documents are lost or corrupted, the LiveCycle ES server may become unstable. Input documents for asynchronous job invocation are also stored in the GDS and must be available in order to process requests. Therefore, it is important that the GDS is stored on the redundant array of independent disks (RAID) and backed up regularly.

In general, it is not recommended to make any manual changes in the GDS directory as doing so can cause issues in your LiveCycle server leaving it in a unstable state.  This information is provided as an explanation of the directories within the GDS only, and should not be seen as a guide to making changes.


The GDS can contain the following sub-folders:

1. audit –  This folder is used to store ‘Record and Playback’ data when recording is activated through Workbench.  ‘Record and Playback’ can be turned on/off at the orchestration (process) level.  If you turn it on for a particular process, it will save data in the /audit folder for every invocation of the process.

Running load testing on processes with recording turned on is therefore not recommended as this can fill up your hard disk.  You can purge the audit folder without consequences (apart from losing your process recordings).  It is best to purge it by using Workbench to delete process recordings.

2. backup – This folder is used to store data related to using LC backup mode.  The folder is managed by LC and should not be modified manually.

3. docmXXX… folders – These folders contain data and files related to long-lived processes.  Do not manually modify the docm folders otherwise the GDS may get out-of-sync with the DB and you will have to restore from a backup.

Once the process instances are completed or terminated, you can clean them using the purge utility in the SDK, if it is Ok for your organization to clean archived process data.  Once the completed/terminated process instances are purged using the purge utility, the related docm folders will also be cleaned by LC.  This can be useful to control the disk usage of the LC server.

4. removeOn.XXX… folders – These folders contain data related to the running services in LC.  They are managed by LC and cleaned automatically after document disposal timeout

5. sessionInvocation-adobews__XXX… – These folders are created by LC when performing document operations when the LC7 compatibility layer is installed.  The remaining empty folders can be cleaned up manually even when the LC server is running without breaking any dependencies.  This is important on some platforms like AIX where there is a kernal limit (~32,000) on the number of sub-folders in a folder.  There is a patch available for LiveCycle ES2 to prevent these folders being created when the LC7 compatibility layer is installed.  Contact enterprise support if you require this patch.

6. sessionJobManager-XXX – These folders are created by LC when using watched folders to perform document operations.  They are managed by LC and should not be modified manually.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 3.4/10 (7 votes cast)
LiveCycle ES: explanation of GDS directories, 3.4 out of 10 based on 7 ratings

Comments are closed.