refusing to delete pre-existing snapshot {}: its metadata ta

Error message

refusing to delete pre-existing snapshot {}: its metadata targets a different worktree than {}

What it means

When a pre-existing snapshot carries metadata (owner worktree/session), `create_snapshot_with_symlink` checks it with `snapshot_meta_state`. A `Mismatch` means the metadata proves the snapshot belongs to a different worktree/session than `dest`, so the library bails instead of deleting another session's snapshot. This is a deliberate ownership guard against cross-session data loss.

Source

Thrown at crates/codegen/xai-fast-worktree/src/btrfs/snapshot.rs:161

            bail!(
                "refusing to delete pre-existing snapshot {}: outside grok-managed \
                 btrfs storage",
                snapshot_path.display()
            );
        } else {
            match snapshot_meta_state(&snapshot_path, dest) {
                // Recreate a stale snapshot for this worktree, or reclaim a
                // crashed-creation orphan whose metadata was never written; the
                // is_safe check above keeps the delete inside managed storage.
                SnapshotMetaState::Matches | SnapshotMetaState::Absent => {
                    tracing::warn!(
                        snapshot_path = %snapshot_path.display(),
                        "snapshot path already exists for this worktree, recreating"
                    );
                    delete_snapshot(&snapshot_path)?;
                }
                // Metadata proves a different session owns it — never delete.
                SnapshotMetaState::Mismatch => bail!(
                    "refusing to delete pre-existing snapshot {}: its metadata targets a \
                     different worktree than {}",
                    snapshot_path.display(),
                    dest.display()
                ),
            }
        }
    }

    tracing::info!(
        source = %snapshot_source.display(),
        snapshot = %snapshot_path.display(),
        dest = %dest.display(),
        "creating BTRFS snapshot with symlink"
    );

    // Create the snapshot inside the btrfs filesystem
    create_snapshot(snapshot_source, &snapshot_path)?;

View on GitHub (pinned to bc7f02eddd)

Solutions

Read the error: it names the conflicting snapshot path and the intended dest; confirm which session truly owns the snapshot.
Choose a unique dest/snapshot path per session so paths don't collide across sessions.
If the foreign snapshot is stale and confirmed unowned, delete it manually (`btrfs subvolume delete` or the library's `delete_snapshot` only if you own it) and retry.
Do not try to bypass the check by editing metadata unless you fully control both sessions.
Investigate why two sessions derived the same snapshot path — usually a dest id collision or restored state.

Example fix

// before
// session B reuses session A's snapshot path
let dest = Path::new("/srv/wt/shared-id"); // meta says owned by session A
create_snapshot_with_symlink(&src, dest)?; // refuses
// after
let dest = Path::new("/srv/wt/session-b-unique-id"); // distinct id per session
create_snapshot_with_symlink(&src, dest)?;

Defensive patterns

Strategy: try-catch

Validate before calling

use std::path::Path;
fn no_foreign_snapshot(dest: &Path, snapshot_path: &Path) -> bool {
    !snapshot_path.exists()
        || match crate::btrfs::snapshot::snapshot_meta_state_public(snapshot_path, dest) {
            Ok(crate::btrfs::snapshot::MetaState::Match | crate::btrfs::snapshot::MetaState::None) => true,
            _ => false,
        }
}

Try / catch

match create_snapshot_with_symlink(&src, &dest) {
    Err(e) if e.to_string().contains("targets a different worktree") => {
        eprintln!("snapshot owned by another session — pick a new dest or clean up the old session: {e}");
    }
    r => r?,
}

Prevention

Guarantee one dest id per session — never reuse snapshot paths across sessions
Track session lifecycle and delete snapshots when a session ends
On restore/clone of environments, strip foreign snapshot metadata
Log dest ids so collisions between concurrent sessions are easy to spot

When it happens

Trigger: Calling `create_snapshot_with_symlink` with a dest whose snapshot path already exists and whose embedded metadata points at a different worktree id than the current dest.

Common situations: Reusing the same snapshot path across two concurrent sessions; dest renamed/moved so its id differs from the recorded owner; cloned or restored environments carrying foreign snapshot metadata; leftover snapshots from deleted sessions.

Related errors

AI-assisted analysis of xai-org/grok-build@bc7f02eddd (2026-08-31). Data as JSON: /api/errors/01ebca6e281e14de. Report an issue: GitHub.