Overview

To aid in ingest or to provide services for external content, Fedora 4 has the ability to expose that external content, as if it were included in a part of the repository.  Federation may be useful for migrating content into Fedora 4 or serving large files already on disk.

...

• Filesystem federation is read-only, currently.
• Access control can currently only be applied to an entire federated filesystem, not sub-directories/files within the resource.
• Transactions are not available.
• Versioning is not availablesupported.
• Querying using the internal search functionality (including calculating object and byte counts in the repository root) results in every file and directory being accessed each time the caching timeout expires (this is set with the cacheTtlSeconds parameter).  For federations with large numbers of files, this can take a long time and result in the operating system "Too many open files" errors as files are opened faster than Java garbage-collects them.

...

One use case for filesystem federation is for external datastreams – storing objects in the repository, but linking to large files on disk instead of ingesting them as datastream content.  To do this, copy the file to the federated filesystem directory, then create the object in Fedora using the REST API linking to the federated filesystem content using the "Content-Type" header as follows (see: PUT):

"Content-Type: message/external-body; access-type=URL; URL=\"http://localhost:8080/rest/federated/file\""

...

For a connector, even a read-only connector, some properties are computed and stored.  These include a modification date and a checksum (if enabled) which is only recomputed when the file is altered.  If it is not desirable or possible to store these properties on the same file system path that is being projected over, you may specify an alternate location (propertiesDirectoryPath) in which those properties will be cached.  This is especially important when using checksums in directories of large files.

...