The files in the repository managed by Remository can be stored in the database. When that happens, a file is split up into 64 KB chunks for manageability, and stored as a series of “blobs” in the xxx_downloads_blob table.

Database storage is the recommended option, and is the default when Remository is first installed. It provides excellent security. Even if a file did have malicious content, it is incapable of doing anything when stored in a database table. (Obviously you still have to guard against serving malicious content to users of your web site).

Each container in Remository has provision for setting groups that can do various things. The four options are upload, download, edit and auto-approve. You can enter as many groups as you wish. It is possible for Remository to manage the groups, but since Joomla introduced more flexible groups, it is normally more sensible to use the CMS groups. This can be selected in the “Options” for Remository. There is a pseudo-group called “Nobody” which never has any members and disables the relevant facility.

The first three settings are self explanatory. Auto approve is a little more complex. What it means is that when a user uploads a file, if the user is a member of one of the groups set for auto-approve, then the file will be immediately published and available for download. If the user is not a member of any of the auto-approve groups, the uploaded file is held for approval by an administrator through the Remository admin interface.

Storing files in the database is secure and flexible, as it does not depend on quirks of hosting. Moving a site can be achieved entirely by moving the database tables and installing Remository.

But it is possible to have the file store in the disk system. You can set this as a default in the “Options”. There is a default path to the file store which is shown in the front page of the Remository admin interface. When a new container is created, it will first appear with the default path. You can choose a different path. It is important to do this carefully, both to avoid conflicts with other activities on the system and to ensure security. The file repository should not be accessible by the web server. This can be achieved either by ensuring that it is outside the web root, or by web server configuration directives.

Where files are stored in the file system, Remository will move them if the container is updated with a different absolute path. If the container's absolute path is deleted altogether, Remository will move the files into the database. If an absolute path is stored for a container that previously used the database, Remository will move the files out of the database and into the file system.

A further choice can be made for files stored in the file system with the “Real With ID” selection in the “Options”. Each file in the repository is allocated a unique ID number by Remository. If “Real with ID” is set to yes, Remository will insert the file ID into the file name before the final extension. So a file with ID 65 and called my.example.file.pdf would then be stored as my.example.file.65.pdf. Users will not see this - when the file is downloaded or displayed, the number is removed. If the option is changed to “no”, Remository will remove the ID numbers from all the files.

A software library exists that can make Remository file handling more abstract. It includes the ability to add more choices for storing the repository. The choice that is currently available is to use the Amazon S2 data storage system. Other similar storage systems could be implemented, including those by Google and Microsoft. This software has been used in custom versions of Remository for clients. It will at some point be introduced into the standard release. If you would like to accelerate this process, please consider sponsoring the development effort.