B2 Files

Inventory and manage Backblaze B2 file versions via the Native API v4 — an aggregate scan that separates current bytes from the non-current versions a bucket with no hidden-version lifecycle rule pays for forever, plus sync, copy, and gated hide, delete and Object Lock updates.

First publish of @sntxrr/b2/files — inventory and manage B2 file versions via the Native API v4.

Aggregate scan separates current bytes from the non-current versions a bucket with no hidden-version lifecycle rule pays for forever, plus sync, copy, and gated hide, delete and Object Lock updates.

Live-verified against a real account: a full fleet scan of 2,693,460 versions sized 39.49 GiB of non-current data. That run found and fixed three contract-level defects no mock test caught:

• B2 omits legalHold and fileRetention entirely on buckets without Object Lock, so a zero lock count meant "not reported" rather than "not locked" — lockFieldsAbsentCount now models absent, unreadable and readable as three distinct states.
• sync, delete and update forced a bucket-ID lookup their B2 calls never need when addressed by fileId, locking out bucket-restricted keys without listBuckets.
• copy resolved the destination bucket name after the copy had landed, stranding a completed side effect behind a failed method.

Every version-derived metric is nullable: null means "not measured", never zero. Read the truncated flag before reading any byte total — the default maxPages of 50 caps buckets past roughly 500k versions.