[leifrossau]

Problem

When a new file is uploaded for the first time, the server can report it in a delta before the upload loop notices that the upload completed. Two things go wrong in that window:

1. A rewrite made during the first upload is silently lost. applyDelta matches the item by name and calls MoveID(localID, serverID), which uses DeleteID → CancelUpload. If the file was written again while the first upload was running, that second queued upload is dropped: the new content stays local only and the server keeps the old content.
2. A server-side rename or move in that window is lost. The delta can't be matched by name, so applyDelta adds a second inode under the server ID; the upload loop's later MoveID overwrites it with the local one, so the file keeps its old name and the server ID is listed twice in the parent.

Fix

• MoveID moves a pending upload to the new ID instead of cancelling it. Only the upload loop touches its sessions, so MoveID sends a request on a new moveQueue and waits for it before moving the inode. The session is re-keyed in memory and in bolt and from then on uploads by item ID; if a session for the new ID is already queued, it is newer and wins.
• DeleteID is split into deleteID (no upload cancel) and DeleteID; moveID, the inode-only part of MoveID, uses deleteID.
• On a completed upload that produced a new ID, the upload loop moves the session and inode directly (it can't wait on itself), and no longer queues a cancellation to itself on every first upload.
• UploadSession.Upload reads the session ID once under the lock, since the ID can now change while an upload runs.
• If an inode already exists under the new ID, moveID applies its name and parent to the moved inode and removes it instead of overwriting it.

Testing

• New offline tests in fs/move_id_offline_test.go: TestMoveIDKeepsPendingUpload and TestMoveIDMergesInodeAddedByDelta (both fail on the old code), and TestUploadCompletionMovesID (no deadlock in the upload loop's own path).
• go build ./... and go vet ./... pass. I could not run the live-account suite.

Notes for reviewers

• MoveUpload blocks until the upload loop handles it and must not be called from the upload loop; callers (applyDelta, remoteID) hold no inode locks at that point.
• Between the delta and the next upload-loop tick (2 s), a renamed new file can briefly appear under both names.
• MovePath (renames) still cancels pending uploads through DeleteID — same kind of bug; I'll send a small follow-up once this is in.
• Merges cleanly with the upload in-flight PR.

🤖 Generated with Claude Code