The Copy You Never Sent

The friction

There is one supported way to reclaim disk space from Messages without navigating by hand to a years-old conversation: the attachment list in System Settings ▸ General ▸ Storage ▸ Messages. It has a Size column, a sort arrow, and a Delete button.

It does not show you your largest files.

On the machine that prompted this filing, the biggest single attachment in the store — an 814 MB PNG — was absent from the panel entirely. Not buried, not mis-sorted. Absent.

Nor was it in the conversation. The user scrolled a 15,000-message thread back two and a half years to the exact date, found the discussion of the image, and found no image bubble for it. Two independent surfaces, both blind to the same 814 megabytes.

The correction

The first version of this filing said the recorded size was simply wrong — off by up to 8279× — and that Apple had wired the panel's filter to a lying field. That was a misreading, and it cost the user most of a day hunting a bubble that could not exist.

total_bytes is not wrong. It records what Messages actually transmitted.

Send a file larger than iMessage will carry and Messages does not refuse. It compresses a copy, sends that, and keeps your original on disk, attached to the same message. One message, two attachments:

That one fact explains both blindnesses. The panel filters on transmitted size, so a 5.6 MB record never clears the threshold however large the file is. And the transcript renders the transmitted attachment, so the original — never sent, never part of the conversation — has no bubble to find. It is not hard to locate. It is not locatable.

The real damage is not disk space

The staged original is frequently the only full-quality copy in existence. The recipient has the compressed version. You have the original — filed where no interface will show it to you.

On this machine: 8.57 GB across 43 conversations, overwhelmingly family video. A 278.6 MB clip transmitted as 216 KB. A 174.3 MB clip transmitted as 19.3 MB.

Now consider what macOS offers a user whose disk is full. Messages ▸ Settings ▸ General ▸ Keep messages ▸ 1 Year — the one-click remedy, which on this machine would have freed 109.7 GB. It would also have destroyed every one of those 8.57 GB of originals: silently, with no warning, no listing, and no way to have known they were there.

Apple's storage advice and Apple's hidden originals are on a collision course, and the user is never told.

Three observations, in order

1. Every visible row went out uncompressed

   Reading the panel's top ten against the database, total_bytes for those rows ranged from 233 to 758 MiB. Not one small value among them.

2. Every huge missing file was compressed on the way out

   The six omitted files above occupy 3.6 GB between them and were transmitted as 46.5 MB in total. The worst, IMG_6510.MOV, went out as 0.08 MiB and kept 695.8 MiB on disk.

3. The display is honest even though the filter is not

   The panel's sizes fall monotonically and match stat converted to decimal MB. So the sort and the column read the filesystem. Only the decision about which rows exist reads the database.

What Sal would say

“The power of the computer should reside in the hands of the one using it.”

Principle #2 — solve a real problem. The real problem is a full disk. Apple correctly identified it, built a panel for it, and shipped it in the default OS. Then the panel answered a question the user did not ask — which attachments were recorded as large at transfer time — while appearing to answer the one they did: which attachments are large right now.

That is worse than having no tool. A missing feature sends the user looking for another way. A tool that silently omits the answer sends them away believing there is nothing more to find. The user in this case deleted several hundred megabytes of family videos from the visible list while a 1.55 GB duplicated PNG sat two rows above the top of it, invisible — with 49 GB free on a 1.8 TB disk.

Principle #5 — use what the user already has. The real sizes are on the filesystem, which the panel already reads to render its Size column. Nothing needed inventing. It had to ask the disk twice instead of once.

And a principle this filing had to learn the hard way: if you keep something on a person's behalf, tell them you kept it. Messages made a decision — compress this, send the small one, keep the big one — and recorded it nowhere the person could see. Every downstream failure follows from that silence.

What it should be

1. Filter on the size you display.

for each attachment row in chat.db:
    path = resolve(row.filename)     // already done — the panel shows this file
    size = stat(path).st_size        // already done — this is the Size column

    if row.total_bytes >= threshold:   // current: the size that was SENT
    if size >= threshold:              // what it should be: the size on DISK
        show(path, size)

No new API, no new permission, no schema change, no performance argument — the panel already stats every file it lists to render the column. It stats the survivors. It needs to stat the candidates.

2. Name the thing. An attachment whose on-disk size exceeds its transmitted size is a staged original. Label it as one, in the panel and in the ⌘I grid: “Original — 278 MB. Sent as 216 KB.” One line of text ends the entire confusion.

3. Warn before destroying originals. “Keep messages ▸ 1 Year” should say: this will also delete 1,340 original photos and videos that exist only here — with a button to export them first.

4. Offer the choice at send time. The user was never asked whether to keep an 814 MB original. Ask, once, and remember the answer.

5. Surface duplicates. Sending one video to three people stores it three times — 2.5 GB of byte-identical redundancy among files ≥100 MB on this machine alone.

The compounding problem

This lands on top of MESSAGES-001. Messages exposes exactly three AppleScript commands — send, log in, log out — and no attachment class, so there is no scripted path to deleting an attachment at all. The UI is the only supported surface.

Which means the broken panel is not one option among several. For the files it conceals, the only remaining route is to remember which conversation something was sent to, open it, and scroll a grid with no size column back through years — and for staged originals even that fails, because there is no bubble to click.

A user cannot see their own largest files, cannot reach them by hand, cannot script around it, and is offered a remedy that would delete the irreplaceable ones without saying so.