Data managed in file storage deprecated
Data managed in file storage
This paper attempts to outline what type of data is stored in file storage like NFS, S3, Scality or whatever storage connector is utilized.
2.Types of data held in file storage
All file attachments bound to PIM objects (appointments, tasks, & contacts) are stored to the context-associated file storage and therefore are accounted to the overall context-assigned quota usage.
The number of allowed attachments is configured through property
com.openexchange.quota.attachment, which controls how many attachments are allowed tob e uploaded in context.
Files uploaded/managed in Drive module are either stored to the context-associated file storage, but may also be managed in a dedicated user-associated one to have a user-sensitive drive-only quota usage and limit.
Application-generated files that are worth being cached (e.g. generated thumbnail images) are held in FIFO manner in a resource cache. Provided that the cache is enabled (
com.openexchange.preview.cache.enabled=true) and configured to utilize the file storage through setting
com.openexchange.preview.cache.type property to
FS (default), then files associated with that resource cache are stored to the context-associated file storage and therefore are accounted to the overall context-assigned quota usage if setting
com.openexchange.preview.cache.quotaAware is set to
true (default is
Further configuration options are:
com.openexchange.preview.cache.quotaSpecifies the total quota for preview cache for each context. This option if config-cascade aware and thus allows specifying individual values. A value of zero or less means no quota. Default is
com.openexchange.preview.cache.quotaPerDocumentSpecifies the quota per document for preview cache for each context. This option if config-cascade aware and thus allows specifying individual values. A value of zero or less means no quota. Default is
Moreover, an administrator is able to manually clear entries belonging to that cache either globally or for a certain context through the 'clearpreviewcache' command-line tool.
Snippets (aka Signatures)
In case the system signals that file storage is available through advertising
true for property
com.openexchange.capability.filestore created snippets/signatures are created in context-associated file storage and therefore are accounted to the overall context-assigned quota.
com.openexchange.snippet.quota.limitSpecifies the maximum number of snippets that are allowed being created by a single user. A value of less than 0 (zero) means unlimited. Default is
com.openexchange.mail.signature.maxImageSizeSpecifies the maximum size (in MB) for one image contained in the HTML mail signature. Default is
com.openexchange.mail.signature.maxImageLimitSpecifies the maximum amount of images that are allowed in a single HTML mail signature. Default is
In order to support a lossless contact synchronization, the Open-Xchange Server supports to enable a vCard storage. A vCard associated with a contact managed in Open-Xchange contains all properties/attributes received from arbitrary clients that synchronize/exchange contacts with Open-Xchange through the vCard format.
If enabled through property
com.openexchange.contact.storeVCards (default is
true) the vCards are created in context-associated file storage and therefore are accounted to the overall context-assigned quota.
In addition the setting
com.openexchange.contact.maxVCardSize defines the maximum allowed size of a (single) vCard file in bytes. vCards larger than the configured maximum size are rejected and not parsed by the server. A value of
0 or smaller is considered as unlimited. Default is
4194304 (4 MB).
Mail compose attachment
Starting with v7.10.2 the Open-Xchange Server supports a new API for composing a new mail. Whenever the user starts a new mail a dedicated composition space is created, that reflects the current state of the mail.
Most remarkably such a composition space also supports instant attachment uploads. In contrast to former mail compose API, attachments are now stored and held in used storage as long as associated composition space is alive.
com.openexchange.mail.compose.maxSpacesPerUserSpecifies the max. number of concurrently opened composition spaces that are allowed for a single user. This configuration option is config-cascade aware and reloadable, but only effective if "com.openexchange.mail.compose.mailstorage.enabled" is set to "false"
com.openexchange.mail.compose.maxIdleTimeMillisDefines the time span in milliseconds a composition space may be idle before it gets deleted. If zero or less than zero is specified, composition spaces may be idle forever. Can contain units of measurement: D(=days) W(=weeks) H(=hours) M(=minutes). Default is 1W (1 week). This configuration option is config-cascade aware and reloadable.
Those two configuration options specify how many composition spaces are allowed to be created and how long they are allowed to exist (when idling). To directly address storage possibilities, there two possible ways to operate:
Default (context-associated) storage
By default, uploaded attachments are stored in context-associated file storage, but without affecting its quota. Meaning, attachments are managed in context-associated file storage regardless of any quota limitations that were specified during context provisioning. This is the appropriate choice for installations, in which the registered file storage has plenty of space and has not been space-wise restricted according to quota usages.
If the context-associated file storage is used, the "checkconsistency" command-line tool cares about orphaned/non-existent references.
To have a dedicated file storage that is supposed to be used for uploaded attachments to not use the context-associated one, there is the opportunity to specify following configuration option:
com.openexchange.mail.compose.fileStorageIdSpecifies the identifier for a dedicated file storage that is supposed to be used for mail compose attachments. By default that option empty, but config-cascade aware and reloadable.
Once a dedicated file storage is used, the "checkconsistency" command-line tool is not effective for caring about orphaned/non-existent references. Instead, there is a dedicated tooling available named "deleteorphanedattachments".