Upload Fixity

Breakdown of how upload fixity works.

During the resource upload process, fixity is checked in two locations. First, when files are saved to the disk from the request. Second, after files are uploaded to the target.

Image 1: Where in the upload process fixity is checked

Fixity Check 1

Resources must be included in the POST request in BagIt format as a zip file. After unzipping the file and saving it to the server we validate the bag using BagIt's built in validator. If any files saved don't match the manifest originally given then the fixity has failed and the server will return an error.

Generate New Hashes If Necessary

We now know that the currently saved files are the same as what the user sent forward. Before upload resources to the target we will make sure that there is a dictionary of hashes available that are supported by the target. If the target supports a hash algorithm provided by the resource's 'bag' then we will simply use those. If not, then we need to generate new hashes based on a target supported hash algorithm.

Fixity Check 2

After resources are uploaded to the target, we compare the resources' hashes brought back from the target to the hashes we captured before. If any hashes don't match then fixity fails. Since the resources have already been uploaded we simply capture which resources' fixity fails and pass that along the response payload along with the message, 'Upload successful but fixity failed'.