Page tree

Current Release

This documentation covers the current version of Fedora. Looking for another version? See all documentation.

Skip to end of metadata
Go to start of metadata

Fedora supports several modes of maintaining and verifying durability of its digital objects.

Ingest

When uploading binary content, clients may also provide a SHA-1 checksum digest with their request. Fedora will validate the uploaded content against the SHA-1 hash to ensure the data was correctly transferred. In any case, Fedora will calculate and store that information to ensure it has something to run fixity checks against later.

Example

$ curl -X PUT --upload-file @image.jpg -H"Content-Type: image/jpeg" -H"digest: sha=cb1a576f22e8e3e110611b616e3e2f5ce9bdb941" "http://localhost:8080/rest/new/image"
-> 201 Created
 
$ curl -X PUT --upload-file @image.jpg -H"Content-Type: image/jpeg" -H"digest: sha=no-good" "http://localhost:8080/rest/new/image"
-> 409 Conflict
urn:sha1:bad-checksum did not match urn:sha1:cb1a576f22e8e3e110611b616e3e2f5ce9bdb941

Durable storage

Fedora can also be clustered, and replicate or distribute the content across members of the cluster.

Fixity 

Fedora supports transmission fixity and persistence fixity. See Fixity Checking.  Note: On-demand, persistence fixity checks are currently supported, but this service is slated for future deprecation. 

Export

Fedora supports durable, transparent persistence via two optional methods: an export component and an external component, which supports several forms of export serializations. The export component is a separate task that is independently launched.  The latter component listens for repository events that are emitted on all modification actions, retrieves the modified resources and serializes them to disk in addition to the native storage of the repository. Serializations include RDF (text/turtle) or JCR/XML.

  • No labels