It's hard to really say but it could be a client/caching issue.

I can describe ProGet's behavior:

• when adding a blob to a feed, ProGet first requests an exclusive write lock on a file, writes the entirety of the stream to that file while hashing it, confirms the hash, then writes a database entry indicating the successful file write and size
• when downloading a blob from a connector, a race condition may occur when adding the cached file to the feed; this is ignored, and the remote stream is returned
• when performing a Docker feed scan, ProGet will recompute the hash of each blob and report on issues
• when performing a reindex (with deletion), ProGet will perform another hash recompute and delete mismatched blobs

That said, aside from OS-level interference -- which happens A LOT due to endpoint monitoring tools -- we're not aware of any conditions in which a blob is truncated or fails to write. I can't imagine how the integrity check would fail to detect a truncated blob.

The next time you see an error like this, I would check the content on ProGet server itself. For example, when you see this:

e28c9cbe4ea2: Download complete
short read: expected 64432621 bytes but got 38190973: unexpected EOF

Track down the e28c9cbe4ea2 blobfile in the package store. It should have a hash that matches the digest.

Separately, you can test ProGet's behavior by going to the file store and manipulating a blob file. For example, rename abcd1234 to zzz_abcd1234 then copy some other blob and name it abcd1234. That will always fail a hashcheck.

Thanks,
Alana