Skip, Keep Both, Replace, Cancel

"'There's already a file here' is a question for a human, not a coin flip for the app."

The Moment of Collision

You copy notes.txt into a folder that already has a notes.txt. This is the single most dangerous ordinary moment in a file manager, because the wrong default silently destroys data. Replace-by-default overwrites a file the user may have wanted; skip-by-default drops a file they meant to bring. There is no safe guess. The only safe design is to make the collision an explicit decision.

The Choices, and Where They Live

Waygate offers a fixed set: skip (leave the existing file, drop the incoming one), keep both (bring the incoming file under a distinct name), replace (the incoming file wins, but the old one is protected first), merge where supported (for folders), and cancel (stop the whole operation). Crucially, the chosen decision is durable plan input — it's recorded in the operation plan, not read live from some global 'always do X' toggle or inferred from which pane had focus.

Replace Protects Before It Overwrites

Even 'replace' isn't a blind overwrite. Per the accepted collision plan, Waygate first protects or stages the existing destination — so if the operation is interrupted mid-replace, recovery isn't left guessing which version the user wanted. The old file isn't gone the instant the new one starts writing; it's preserved until the replace is verifiably complete. And after a crash, recovery never guesses which side to keep — the plan and the journal say what was intended.

Collision choice is explicit, durable plan input — skip, keep both, replace, merge, or cancel — never inferred from focus or a remembered default. Replace protects the existing destination before overwriting, so an interrupted replace is recoverable and a crash never forces the app to guess which version to keep.

The silent 'always replace' toggle. The single most dangerous UI in a file manager is a remembered global 'apply to all / always replace' setting that silently governs future operations. A collision six weeks later gets resolved by a checkbox the user forgot they ticked, and a file is gone. Waygate keeps the decision on the operation, in view, at the time it matters — not in a sticky global that ambushes you later.

Code

The decision is data on the plan, not a live global·swift

enum CollisionDecision {
    case skip            // keep existing, drop incoming
    case keepBoth        // bring incoming under a distinct name
    case replace         // incoming wins -- but protect the old one first
    case merge           // folders only, where supported
    case cancel          // stop the whole operation
}

func applyReplace(_ incoming: URL, over existing: URL, _ plan: OperationPlan) async throws {
    // Protect the existing destination BEFORE the incoming file lands:
    let backup = try await stageExistingForReplace(existing, plan)
    try await journal.mark(plan.id, .replacedDestProtected, evidence: backup)
    try await publish(incoming, as: existing)        // now the swap is recoverable
    // A crash between these lines -> journal knows the old file is staged,
    // recovery restores or completes deterministically, never guesses.

Exercise

List every collision default you've seen a file tool use (replace, skip, auto-rename, ask). For each, invent a realistic case where that default silently does the wrong thing. Then decide: which of these are safe as a per-operation choice the user makes in view, and which are dangerous as a sticky global?

Hint

Every automatic default has a case where it's wrong: replace loses a newer file, skip drops the one you wanted, auto-rename litters duplicates. That's why 'ask, in context' is the safe baseline. Any of them is acceptable as an explicit per-operation choice you can see; all of them are dangerous as a persistent global that resolves collisions you're not even watching.

Skip, Keep Both, Replace, Cancel

The Moment of Collision

The Choices, and Where They Live

Replace Protects Before It Overwrites

Code

External links

Exercise

Progress

Comments 0