Fedora 4 supports several modes of maintaining and verifying durability of its digital objects.
Ingest
When uploading binary content, clients may also provide a size and SHA-1 checksum digest with their request. Fedora will validate the uploaded content against the SHA-1 hash to ensure the data was correctly transfered. In any case, Fedora 4 will calculate and store that information to ensure it has something to run fixity checks against later.
Example
$ curl --upload-file image.png "http://localhost:8080/rest/fcr:new/fcr:content?checksum=urn:sha1:5441456941dd8b3ee0832b991ee93ba0c0a558f7" -> 201 Created $ curl --upload-file image.png "http://localhost:8080/rest/fcr:new/fcr:content?checksum=urn:sha1:bad-checksum" -> 409 Conflict urn:sha1:bad-checksum did not match urn:sha1:5441456941dd8b3ee0832b991ee93ba0c0a558f7
Durable storage
Fedora 4 can be configured to retain duplicate copies of binary content.
Fedora 4 can also be clustered, and replicate or distribute the content across members of the cluster.
Fixity
If your repository is configured to retain multiple copies of binary content, when you request a fixity check of that content, Fedora will run fixity checks against each copy it stores. It will also "self-heal" all copies of the content, if it has a good copy available.
Requesting one-off fixity checks of objects is baked into the core HTTP API.
Fedora Futures developed a fixity queueing and reporting service (that is only loosely coupled to Fedora - outdated project).
Export
