#25189 acpmux: an upload has no size cap, only the disk's room; cancel deletes its partial file

Leo, 2026-10-24: "I thought we removed the file size limit attachment situation... we shouldn't have this limit."
Leo, 2026-10-25: "like arbitarrily large file sizes the composer should never ever freeze and prevent new things from happening/from cancelling the thing"

The daemon side of uploads to a chat that runs on another machine (an ssh peer, or this Mac's acpmux when the app sends a file there). _acpmux/file_put_begin refused any file over 1 GiB. A 2 GB video could not attach.

What changes

• No size cap. file_put_begin refuses a file only when the disk of the machine that runs the chat lacks room for it plus a 256 MiB reserve. The refusal is filePut.noSpace with machine and freeBytes, and its message reads: "Not enough space on huge-blue for movie.mov (1.2 GB free)". It replaces filePut.tooLarge here. A chunk the disk can't take mid-upload (StorageFull/QuotaExceeded) is refused the same way, and its partial file is deleted so the space comes back.
• The one-shot _acpmux/file_put keeps its 10 MiB bound (LEGACY_MAX_BYTES): it crosses a peer link as one WebSocket frame, and an older peer reads at most 16 MiB. It also checks free space now. Chunk size (512 KiB) and the peer-forward checks are unchanged.
• Streams to disk. Each chunk is appended through one file. Before, every chunk ran sync_data, which made a large upload wait on the disk thousands of times. Now the file is synced once, at the finish, before it is renamed into place.
• Cancel deletes everything. file_put_cancel deletes .part, .meta and the upload's own folder (remove_dir, so only an empty one). Before, it left the folder behind. It still succeeds when called again.
• Abandoned uploads go. The daily sweep deletes an upload that still has a .part once it is a day old, even with uploadsMaxAgeDays: 0. That covers a client that went away without a cancel.
• server/peer_status.rs's statvfs helper is now pub(crate) and does the room check. On Windows it reports nothing, so any size is tried there.
• server/remote_guard.rs: a doc comment only (it named the removed MAX_BYTES).

The app side is a separate PR. It streams each chunk straight to this daemon, with no copy on the Mac, and moves decoding and writing off the main thread.

Tests

Red commit 6654f6ab8b1, fix 3a065a054f8:

• cargo test -p acpmux --test file_put (huge-blue, Linux)
  • at 6654f6ab8b1 (the new tests on base code): 8 passed, 2 failed. a_file_past_the_old_cap_streams_and_one_the_disk_cannot_hold_is_refused_for_space failed because begin refused 1 GiB + 1. a_streamed_file_for_a_peers_chat_lands_on_the_peer_and_a_cancel_deletes_it_there failed because the peer kept the cancelled upload's folder.
  • at 3a065a054f8: 10 passed.
• cargo test -p acpmux --lib file_uploads: 8 passed. New: a_file_of_any_size_goes_while_the_disk_has_room_for_it, free_space_reads_in_finder_units, the_sweep_deletes_an_unfinished_upload_once_it_is_a_day_old.
• cargo clippy -p acpmux --all-targets -- -D warnings: clean. cargo fmt --check: clean. cargo check -p acpmux --target x86_64-pc-windows-gnu: builds.
• scripts/cmux-next/prepush-gate.py: no new violations.

Observed / Not run

Observed: the runs above on huge-blue (Linux x86_64).
Not run: the macOS suite (hosted verify-cmux-tui-hosted.sh). The room check reads statvfs on both platforms, and CI runs the macOS tests.
Not tested: a real 2 GB upload end to end through the app. The integration test begins 1 GiB + 1 and streams a chunk, and the room math is covered by unit tests.

Overlap: #24626 (an older ten-attachment-limit PR) touches file_uploads.rs. It is not this fix: its chunked transport and 1 GiB cap landed in #24652.

Changelog

Changed: files of any size attach to a chat on another machine; one is refused only when that machine's disk lacks room, with how much is free.

Agent session: huge-blue

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}