Attach a file that is already in Files #96

New Issue

Closed

opened 2026-08-27 17:19:00 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-27 17:19:00 +00:00

Owner

Stacked on #95 — the picker uses the shared-account browsing added there. Review that first; this targets shared-with-me so the diff stays honest.

Attaching meant uploading, even when the file was already in the account — picking it off disk again to send the server a copy of what it was holding.

Your own files cost nothing

A blob the account can already see needs no upload. An attachment carrying a blobId is exactly what a forward produces, so the send path has always known what to do with one. Attaching a large file the server is already storing is now instant.

Shared files are copied, and say so

Blobs belong to the account they were uploaded to, so a draft in yours cannot reference one in theirs. Files from a shared account are fetched and uploaded to yours — and the picker says so before you attach, rather than leaving someone wondering why one file was instant and another wasn't.

The picker borrows the Files store, so it browses what Files browses, shared accounts included, and puts the file manager back where it was on the way out. A detour through someone's shared folder to find an attachment shouldn't leave Files somewhere else afterwards.

Verified — and how, because the first attempt measured nothing

client.upload uses XMLHttpRequest, since it reports progress. A counter wrapped around fetch therefore sees no uploads whether or not any happen, and agrees with whatever you hoped. Counted at XHR instead:

	uploads
attach your own file	0
attach a shared file	1, to your own account

328 web and 77 server tests pass. npm run typecheck clean.

🤖 Generated with Claude Code

_{Rebuilt from: session transcript.}

Stacked on #95 — the picker uses the shared-account browsing added there. Review that first; this targets `shared-with-me` so the diff stays honest. Attaching meant uploading, even when the file was already in the account — picking it off disk again to send the server a copy of what it was holding. ### Your own files cost nothing A blob the account can already see needs **no upload**. An attachment carrying a `blobId` is exactly what a forward produces, so the send path has always known what to do with one. Attaching a large file the server is already storing is now instant. ### Shared files are copied, and say so Blobs belong to the account they were uploaded to, so a draft in yours cannot reference one in theirs. Files from a shared account are fetched and uploaded to yours — and the picker says so before you attach, rather than leaving someone wondering why one file was instant and another wasn't. The picker borrows the Files store, so it browses what Files browses, shared accounts included, and puts the file manager back where it was on the way out. A detour through someone's shared folder to find an attachment shouldn't leave Files somewhere else afterwards. ### Verified — and how, because the first attempt measured nothing `client.upload` uses `XMLHttpRequest`, since it reports progress. A counter wrapped around `fetch` therefore sees no uploads whether or not any happen, and agrees with whatever you hoped. Counted at XHR instead: | | uploads | | --- | --- | | attach your own file | **0** | | attach a shared file | **1**, to your own account | 328 web and 77 server tests pass. `npm run typecheck` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <sub>Rebuilt from: session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#96