Check MD5

Hi!

I did not find documentation about the check md5.
I found two references.

NEWS:
Version 0.5.2 (2013/05/07)

  • Check MD5 of third party downloads

Version 0.7.3 (2014/02/14)

  • Automatic computation of MD5 hashes for the stored DICOM files

Orthanc - REST API:
/{resourceType}/{id}/attachments/{name}/compressed-md5
/{resourceType}/{id}/attachments/{name}/md5
/{resourceType}/{id}/attachments/{name}/verify-md5 - Check that there is no corruption on the disk

My question is if I can check the integrity of the zip file after use GET /studies/{id}/archive.

Thanks!

Vinicius

Hi,

Sorry for the delay. You are perfectly right: The MD5 feature has not been properly documented. It has been implemented thanks to discussions with Karsten Hilbert, from the GNUmed project.

The request was to be able to check for disk corruption in the DICOM files that are stored by Orthanc in a production environment. Since Orthanc 0.7.3, whenever Orthanc stores a DICOM file on the disk (or any attachment), it stores its MD5 in the SQLite database. An exception is generated if the MD5 does not match when reading back the file from the disk. Note that there is a configuration option to disable this MD5 feature (“StoreMD5ForAttachments”).

The MD5 hash of a DICOM file can be retrieved with the REST API:

curl http://localhost:8042/instances/a6d93769-f1471e04-475ae3de-2d8c3220-e9d41702/attachments/dicom/md5

It is also possible to manually trigger a check of the MD5:

curl http://localhost:8042/instances/a6d93769-f1471e04-475ae3de-2d8c3220-e9d41702/attachments/dicom/verify-md5 -X POST -d ‘{}’

Any error while processing this request would mean that there is disk corruption for this instance. A background process could use this API to periodically check for disk corruption.

The feature “Check MD5 of third party downloads” from Orthanc 0.5.2 simply consists in checking the MD5 of the files that are downloaded by CMake when building Orthanc from source.

Finally, regarding your question about checking the integrity of ZIP files that are produced by “GET /studies/{id}/archive”, this is actually a built-in feature of the ZIP file format. Indeed, every ZIP file carries its CRC information:
https://en.wikipedia.org/wiki/Zip_(file_format)#File_headers

For instance, the standard command-line tool “unzip” allows to check this CRC with the “-t” flag.

HTH,
Sébastien-

Sébastien, thanks for reply.
Problem solved.