Skip to the documentation
Knowledge base

Files

Every attachment this mailbox holds, in one place you can search, download and clear out.

Details

  • Attachments have always lived in storage scoped to the mailbox they arrived at. What did not exist was any way to ask a question about them. A bucket lists keys and knows nothing about names, sizes, or which message used a file. Files is that index: search by name, filter by kind, see what each one weighs, and open the message it came on.
  • Mail you SEND is kept too, which it was not before. Sent attachments were previously recorded as names with no bytes behind them, so downloading one produced an empty file rather than an error. The half of “my files” people most often go looking for was unreachable. It covers every mailbox and every message in it, sent and received alike.
  • Deleting a file removes the bytes and keeps the row, so Files itself knows the difference between a file that was deleted and one that never existed. The message does not: the attachment still lists on the thread and downloading it fails the way any missing object fails, rather than saying it was removed. That is the half of this that is not built.
  • On a shared mailbox you see files that arrived at the addresses granted to you, the same boundary the thread list uses. Deleting is the owner’s, because being able to read what came to an address is not the same permission as being able to destroy it.
  • There is no backfill. Files lists what arrives from the day the index shipped, so an established mailbox starts empty and fills as mail comes in; older attachments are still on their messages and still download from there.
  • Storage is counted but not capped. The total on the page is the bytes actually held, attachments included, which is what makes it the first honest storage number in the product.