Store every image in one bucket so dedup means one copy

Fixkamo-shared-library
Shipped
August 6, 2026 at 8:13 PM UTC
Author
Kamo
Commit
3045cc3

Association is metadata, not a storage boundary. Each ImageAssocType used to name its own MinIO bucket, which contradicted the hashing pipeline: dedup is scoped ORG-wide or GLOBALly and therefore crosses associations, so reusing an ImgDat produced an Img whose bytes sat in whichever bucket first received them. Reads resolve the bucket from the row's own association, so they looked somewhere the bytes had never been and 500'd. The previous commit patched that by COPYING the objects into the target bucket, which kept N copies of a file the content-addressed store exists to hold once. Reverted. Storage is now a single "imaging" bucket keyed by ImgDat id, so a file is stored once no matter how many associations reference it, and registerExistingDocument uploads nothing — as its name always implied. Safe because buckets were never a boundary here: all imaging buckets were private under one credential, access is enforced by getDocumentMetadata (org + access level), imaging never deletes bytes (deleteDocument is soft), and no bucket carried object-lock, retention or lifecycle rules. Keys are globally-unique ids, so the union has no collisions. All 212 existing objects were migrated into "imaging" first; the legacy buckets are left untouched. ImageAssocType keeps every behavioural difference **************** rules, ordinals); it just no longer claims to own storage.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing