Fedora 4 supports several modes of maintaining and verifying durability of its digital objects.
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 http://localhost:8080/rest/fcr:new/fcr:content?checksum=urn:sha1:5441456941dd8b3ee0832b991ee93ba0c0a558f7 --data-binary @image.png -> 201 Created $ curl http://localhost:8080/rest/fcr:new/fcr:content?checksum=urn:sha1:bad-checksum --data-binary @image.png -> 409 Conflict urn:sha1:bad-checksum did not match urn:sha1:5441456941dd8b3ee0832b991ee93ba0c0a558f7 |
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.
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).