Interface: DriveChecksum

A digest the provider publishes for an item's content.

Comparable within one provider — and not always even that. The algorithm name is part of the value for a reason: an adapter reports what the vendor actually published, and the vendors publish different functions of different inputs.

Dropbox — dropboxContentHash, a block-tree construction. It is not the SHA-256 of the file, despite being built out of SHA-256.
Google Drive — md5, a real MD5, and only for binary files. A native Doc, Sheet or Slide publishes no checksum and no size at all; it carries DriveItem.exportOnly instead, and contentVersion falls back to updatedAt for it.
Microsoft Graph — quickXorHash (base64) on OneDrive for Business and SharePoint, sha1/sha256 on personal OneDrive. "The same provider" is therefore not a fine enough grain here: two connections of the same adapter can report incomparable digests for identical bytes.

The rule an app needs: compare algorithm before value, and do not dedup on a checksum across connections without checking both. contentVersion already does — it uses the checksum only behind the provider's own revision, and prefixes the algorithm onto the version string so two algorithms can never collide into "unchanged".

An app that wants one digest it can compare everywhere should hash the bytes it imported rather than the ones the vendor described: @basaltkit/files computes a SHA-256 as they stream past.

Properties

algorithm

> algorithm: string

Defined in: drives/src/provider.ts:52

Lowercase algorithm name as the provider calls it: md5, sha1, sha256, quickXorHash, dropboxContentHash.

value

> value: string

Defined in: drives/src/provider.ts:54

Lowercase hex, or the provider's own encoding when it is not a plain digest.