Fix rollback leaving directories apply created (#838)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #838

Root cause

Agent-mode apply creates missing parent directories (create_dir_all in apply_file_patch_at) for files a patch adds. The agent-mode rollback engine (rollback_package_patch, used by rollback and remove, and fanned out to pnpm/vlt store copies) deleted those files with a single remove_file and never pruned the directories. In site-packages, an empty leftover directory still imports as a PEP 420 namespace package, so import six_safe / find_spec kept succeeding after a "successful" rollback.

Fix

crates/socket-patch-core/src/patch/rollback.rs is the only file changed. After deleting a patch-added file, a new prune_emptied_parents step:

• removes stale __pycache__/<stem>.*.pyc bytecode for a deleted .py file, then the __pycache__ directory if it is now empty;
• removes each parent directory that is now empty, deepest first, and stops at the first non-empty one. The package root is never removed;
• lstats every directory between the package root and the file first. If any of them is a symlink or junction (on Windows, std reports name-surrogate reparse points as symlinks, not directories) or is not a real directory, nothing is pruned, so directories outside the package are never touched;
• relaxes read-only parents (Go module cache) for the rmdir with the same DirWriteGuard apply uses, then restores their mode;
• is best effort: the file delete already committed the rollback, so a directory that can't be removed stays in place and is not reported as a failure.

Apply doesn't record which directories it created. The test is "empty once the patch's files are gone": a package directory that holds only patch-added files cannot have existed with content before the patch.

Tests (red → green)

New unit tests in rollback.rs, landed in a commit of their own (Test rollback prunes dirs apply created) before the fix. On that commit, cargo test -p socket-patch-core --lib rollback::tests::test_rollback_new_file failed 5 tests and passed 1 (the symlink guard case, because nothing was pruned at all). With the fix, all 46 rollback::tests pass:

• test_rollback_new_file_prunes_created_top_level_dir: Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 top-level six_safe/__init__.py
• test_rollback_new_file_prunes_nested_dirs_and_stale_pycache: Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 nested six_safe/sub/__init__.py plus leftover __pycache__
• test_rollback_new_file_keeps_dirs_that_are_not_empty: unrelated files and other modules' bytecode survive
• test_rollback_new_files_sharing_a_created_dir_prune_it: several added files in one new directory
• test_rollback_new_file_prune_never_follows_a_symlinked_dir
• test_rollback_new_file_prunes_created_dir_under_readonly_root: Go-cache 0o555 root, mode restored

Local checks:

• cargo clippy --workspace --all-features -D warnings is clean.
• rustfmt --check on rollback.rs is clean.
• cargo test --workspace --all-features --no-fail-fast: every failure is environmental. The sandbox runs as root, so read-only-chmod tests can't fail their writes, and the self-update/notifier fixtures need exec, network or a tty. None of those tests touch rollback.

CI on e08b11d is green: all suites completed with none failed. Bugbot's first review raised one finding, Windows junctions. That was a false positive: Rust's FileType::is_dir() is false for name-surrogate reparse points. Evidence is in the thread, which is now resolved. Bugbot's re-review of e08b11d found no new issues.

Per-issue checklist:

• Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 top-level directory → test_rollback_new_file_prunes_created_top_level_dir
• Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 nested directory and __pycache__ → test_rollback_new_file_prunes_nested_dirs_and_stale_pycache
• Agent-mode rollback / remove of a PyPI patch that added a file in a new directory leaves the empty directory in site-packages, so Python still imports it as a namespace package #838 remove → goes through the same rollback_package_patch engine as rollback

Not covered: files a patch adds are still not added to .dist-info/RECORD, so pip uninstall without a rollback leaves them behind (the related point in #838). That is a separate apply-side change and is not claimed here.

🤖 Generated with Claude Code

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit e08b11d. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review.

• Head: e08b11da
• CI: 97/97 non-skipped check runs green on this head (3 skipped by path filters). Mergeable with no conflicts against main.
• Bugbot: reviewed e08b11d and found no new issues. Its one earlier finding (Windows junctions) was refuted in-thread: FileType::is_dir() is false for name-surrogate reparse points, so the symlink guard covers them. The thread is resolved.
• Reviewer focus: the prune logic in rollback.rs relies on "empty once the patch's files are gone" rather than recorded created dirs; check that heuristic is acceptable.

---

Generated by Claude Code