Table of Contents
The Centralized File System (or Centralized File Storage or CFS) manages all physical files in the Zimbra Social platform. The CFS supports file storage providers and to make it easy to add file-based features to the Zimbra Social platform (both in the core product as well as add-ons).
The CFS sits deeply in the Zimbra Social API, in between the API for file-based features and the configured storage providers:
In general, users and developers will not directly interact with the CFS. Only when new file-based functionality must be implemented is direct access to the CFS required. For example, to add/update/delete post attachments and their content, code should not access the CFS, but should instead access the add/update/delete methods of the PostAttachments class (which themselves interact with the CFS file store for post attachments). When implementing a new feature such as video transcoding, it may be useful to have a new file store and interact with the CFS directly as a new file-based feature.
The CFS uses file store keys, paths, and filenames to store files:
The file store key is the unique name for a collection of files serving a single purpose/feature and which share authentication logic. It represents a unique set of files that are managed independently of other file stores.
File store keys must be between 3 and 255 characters and cannot contain any characters that are not valid in windows file system paths.
Paths are similar to directories, but are technically used more like keys. Paths can represent multiple values separated by periods. (The period is used for defining sub-paths and is also programmatically accessible via the Telligent.Evolution.Extensibility.Storage.Version1.CentralizedFileStorage.DirectorySeparator property.) For example, a common file system path may be "my\files\are\here" and the similar CFS path would be "my.files.are.here" .
However, there is a technical difference between directories and CFS paths. When querying for files in a directory, files are generally accessed within a single folder, for example, "my\files\are". In the CFS, because paths are treated as keys, files can also be accessed using partial paths, such as "my.files.a", which would match files in the "my.files.are" path as well as the "my.files.and" and "my.files.any" paths.
Paths must be between 0 and 769 characters and cannot contain any characters that are not valid in windows file system paths.
Filenames are the names of the files stored in the CFS. They must be between 1 and 255 characters in length and must not contain any characters that are invalid in Windows file system file names.
Each file store is defined either using an implementation of the ICentralizedFileStore Plugin Type or via the legacy definition with the communityserver.config file using a <fileStore /> node within the <CentralizedFileStorage></CentralizedFileStorage> node.
Creating a new CFS file store is as simple as adding a new file store plugin, deploying the assembly into the site's bin/ folder, and enabling the plugin via Control Panel > Administration > Site Administration > Site Configuration > Manage Plugins.
When implementing new file-based features for the Zimbra Social platform, the CFS should be used for file storage. The CFS provides a simple API for adding, deleting and querying files and paths. See the documentation on the CentralizedFileStorage API for more information.
- Changes to Centralized File Storage from 6.x - How Telligent Evolution 7.0 enabled CFS configuration to be simplified using Centralized File Store groups and Centralized File Store plugins. (This information is compatible with 8.0.)
- How to secure your filestorage folder - Methods of securing files so users who aren't authorized cannot view the post attachments stored within it.
- How to use files stored in CFS file stores - Using the API for adding, deleting and querying files and paths.