Garbage-collect unreferenced uploads #25
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
posta/server#25
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
`uploadstore` (#22) is append-only by design — every successful
`POST /api/v1/uploads` adds a content-addressed file and nothing ever
removes it. Combined with the lack of quota (filed separately), this
means a client that uploads an image, decides not to send it, never
references it again, still pays disk cost forever.
Scope
A periodic (or on-demand) GC pass that:
`upload-.`.
payload — both outbound (sent by this identity) and inbound (sent
to this identity by a peer, though those URLs typically point at
the peer's host, not this one).
ctime/mtime is older than a grace period (e.g. 7 days, so the
`POST /uploads` → `POST /messages` window doesn't race the GC).
Cross-identity uploads are out of scope: each identity owns its own
upload directory; GC operates per-identity.
Acceptance
that prints the planned deletions and (without dry-run) executes
them.
text/v1 and link/v1 stored rows.
Related: #22.