Child pages
  • Audit
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »





0.5 (2011-03-30)




Merritt Fixity Service


Not available

More information:

Curation home page

In our development process for the Merritt repository, we first create a detailed specification for each micro-service and then develop software based upon the specification. Having a specification helps us think through issues and work out problems before we start to write code. It's always helpful to have people reviewing our specifications, to notice issues or implications we may have missed or not fully understood.

Fixity is a method to test for file integrity and corruption. The Fixity service will verify the bit-level integrity of files managed in the Merritt Repository with a two-part test: Is the filesize of each file unchanged? Is the message digest value of each file unchanged?

We note and store the filesize of each file as it is submitted to Merritt. Curators may also include a message digest value for their content during submission. If none is supplied, Merritt will automatically compute a SHA-256 digest during ingest processing.

Each iteration of the Fixity service will compare the stored filesize value with the file in its current state. The Fixity service will also recalculate the message digest and compare with the stored value. If either of these checks results in a discrepancy, Merritt staff will be notified, so they can take preservation action to restore the uncorrupted state of the file using replica copies.

Please read the draft specification, and let us know any thoughts you have in response. In particular, please consider these questions:

  • Although the Fixity service will be integrated with Merritt, it is designed as an independent micro-service. As such, it can verify objects inside of Merritt or any arbitrary web-accessible resources. Would you expect to use this feature of the service to verify content existing outside of Merritt?
  • Any fixity violations detected by the service are reported only to the service provider, that is, to UC3 staff, not to the owners or curators of the content. The idea behind this is that the most likely cause of fixity violations is some sort of hardware failure, which can be best responded to by UC3 staff. Do you envision use cases in which you would want to receive to notifications of violations directly? Are there other kinds of reporting of fixity results would you expect?
  • Do you have an interest in deploying the Fixity service locally to monitor non-Merritt content?
  • What do you think is the appropriate periodicity for fixity checks? (The service will be implemented to take advantage of parallel processing, but the time required to perform a complete iteration of all content items will rise in proportion to the number of those items.)
  • No labels