Incorrect MD5 hashes for 2026-07-22.0 on Azure blob storage

[ThomasWeiss]

Trying to download files from the 2026-07-22.0 release from Azure blob storage, with either the Azure Storage Explorer or the azcopy utility, fails. An azcopy log said: "DOWNLOADFAILED: https://overturemapswestus2.blob.core.windows.net/release/2026-07-22.0/theme=divisions/type=division/part-00000-3d9695ce-2282-56c2-9d25-622b1ec4727f-c000.zstd.parquet : 000 : the MD5 hash of the data, as we received it, did not match the expected value, as found in the Blob/File Service. This means that either there is a data integrity error OR another tool has failed to keep the stored hash up to date."

[lowlydba]

Thanks for flagging the issue Thomas Weiss (@ThomasWeiss)! We're taking a look - this is likely an unintended side effect of some improvements to our release data synchronization that debuted in the 7-22-26 release.

In the meantime, since this is a client-side check, you should be able to bypass it with:

azcopy copy  https://overturemapswestus2.blob.core.windows.net/release/2026-07-22.0/<path> . --check-md5=NoCheck

[lowlydba]

Confirmed and fixed for 2026-07-22.0. The Content-MD5 blob property has been cleared on all blobs under release/, changelog/, and bridgefiles/ for this release, and azcopy downloads now pass (the default --check-md5 FailIfDifferent passes when the property is absent). No data was re-transferred, the underlying bytes were always correct.

Root cause: our S3-to-Azure sync (AWS DataSync) stamps an incorrect Content-MD5 on multi-block blobs. We verified the data integrity directly: the true MD5 of the affected files matches the S3 source exactly, only the stored Azure hash property was wrong. A pipeline fix to prevent this on future releases is tracked internally.

Leaving this open until the next release ships clean. If you hit the same error on any other file, please note the path here.