xarmian 03ff8fc43a fix(BUG-3186): the CLI turns an attachment name into a path Windows can store, on Windows only; stored names stay as given (#1498) ...

A stored attachment name keeps < > : " | ? * (legal and common on Linux
and macOS: "Meeting: notes.pdf"). On Windows those are refused, and a
colon is worse: "a.svg:x.txt" names an NTFS alternate data stream, so the
bytes land in a stream on an empty "a.svg".

- attachments.WindowsPathComponent, beside WindowsDeviceName: reserved
  characters and C0 controls become "_", trailing dots and spaces are
  trimmed, and a device stem gets the "_" prefix. It is for the boundary
  where a name becomes a path, never for the stored name.
- The CLI's safeLocalFilename applies it only when it RUNS on Windows
  (safeLocalFilenameFor(runtime.GOOS, ...), so it is testable on any host).
  Each saver applies its own filesystem's rules, as browsers do.
  The accepted edge is written down there: a Linux CLI writing onto an NTFS
  mount keeps the colon.

Not changed, by lead ruling on the trail: the Content-Disposition name
(it stays faithful; the server cannot know the client filesystem) and the
bundle tar path. Import recomputes that path from the manifest and skips
unmatched blobs silently, so changing it would make older servers drop
bytes. A cross-version contract comment on bundleAttachmentPath says so.

Claude-Session: https://claude.ai/code/session_01Vf8uZmYdsrQqJtbAmjUFSX

2026-09-24 05:25:53 -04:00

..

loadtest-collab

fix(collab): WebSocket dials get their own per-user bucket and a per-user socket cap, and the editor jitters its reconnects (BUG-1308) (#1499)

2026-09-24 04:51:57 -04:00

pad

fix(BUG-3186): the CLI turns an attachment name into a path Windows can store, on Windows only; stored names stay as given (#1498)

2026-09-24 05:25:53 -04:00