In a cloud-drive service, one device deletes a folder while an offline laptop edits a file inside it; what should the server do when the laptop syncs?

## Why deletes deserve their own rule Concurrent edits to the same file have an obvious safe outcome: keep both versions. A delete is different, because one side wants the item to exist and the other wants it gone. There is no conflicted copy of nothing. A cloud-drive service needs an explicit policy for **edit-versus-delete**, and the policy should follow one principle: **never silently lose user content**. ## Detecting it When a folder is deleted, the server does not simply erase rows. It records a **deleted state** (a tombstone) for the folder and each child, with a new revision, and appends journal entries. Later, the offline laptop uploads an edit to `plan.txt` whose base is `r5`. The server checks the current state: the file is marked deleted at `r6`. The base does not match, so the same compare-and-set that catches edit-versus-edit catches this too. Without the tombstone, the server would see an upload for an unknown file ID and could not tell whether it was new or stale. ## The two directions | Situation | Stale side | Safe outcome | |---|---|---| | Folder deleted, offline edit to a child arrives later | The edit | Restore the edited file and its parent path; keep other children deleted | | File edited to r6, offline delete based on r5 arrives later | The delete | Keep r6; the delete targeted a version its author never saw | | File deleted, offline delete of the same file arrives | Neither | No-op; both wanted the same outcome | In both conflicting rows the side that saw less loses its **destructive** effect, while all content survives. ## Restoring the edited file The typical resurrection steps: 1. Detect that the base revision points at a live file that is now deleted. 2. Recreate each missing ancestor folder on the path, as new revisions, so the file has somewhere to live. 3. Commit the uploaded content as the file's next revision. 4. Append journal entries for the recreated folders and the file. 5. Leave every other child of the original folder deleted. Step 5 is a deliberate choice. Restoring the whole folder with thousands of files would override a clear user action because of one edit. Restoring just the minimal path respects both intents: the user wanted the folder gone, and someone also produced new work inside it. Some designs instead place the edited file somewhere visible, such as a recovered-items location, when recreating the old path would be confusing. The essential property is the same: the edit is kept and every device learns about it. ## Tombstones and retention - A tombstone must live at least as long as a device may stay offline and still sync incrementally, meaning the change-journal retention window. - After the window, a returning device must do a full resync; its reconciliation rules then decide what to do with local files that the server no longer lists. - Many services also keep deleted files in a **trash** with version history for a period, which makes a wrong policy decision recoverable by the user. The general theory of tombstones in replicated stores is its own topic; for file sync, the practical need is that deleted state outlives the longest incremental-sync gap. ## Moves make it harder If one device moves a folder while another deletes it, or edits a file inside a folder that was moved, identifying files by stable ID rather than path keeps these cases manageable: an edit to file ID `f_91` applies wherever that file now lives. Path-keyed designs turn ordinary moves into apparent deletes and multiply these conflicts. ## Telling the user A restored file appearing in a folder the user deleted can be confusing. Good clients surface it: a notification or activity-feed entry that the file was kept because it was edited on another device. The system stays safe, and the surprise is explained.