Windows host: renaming a file on a bind mount makes it unusable in the guest until sandbox restart

[albertsikkema-elix]

Environment

• msb v0.7.2 (msb update reports latest), libkrunfw bundled
• Windows 11 Pro 10.0.26100, x86_64, physical machine (Lenovo), Windows Hypervisor Platform
• msb doctor: clean (only warning: no reflink on MSB_HOME)
• Guest image: alpine

Repro

mkdir C:\spike\trace2
msb create alpine --name trace2 --mount-dir C:\spike\trace2:/w
msb exec trace2 -- sh -c "cd /w; echo a > f; cat f; mv f h; echo rc=`$?; cat h; ls -la"

Expected: a, rc=0, a, then a listing containing h.

Actual:

a
rc=0
cat: can't open 'h': I/O error
total 0

• Creating and reading a file works. Any rename breaks it: to a new name, over an existing file (mv -f), and directory renames (mv d1 d2; cat d2/in gives Invalid argument).
• After the rename, the whole directory lists as empty (total 0), not just the renamed entry.
• The error persists after echo 3 > /proc/sys/vm/drop_caches in the guest and in a new msb exec session.
• msb stop + msb start fixes it: the file is then readable and listed correctly.
• A second sandbox mounting the same folder sees the correct state.

Host side is intact. After the failing rename, on Windows:

• h exists with the correct content, and f is gone.
• The msb.override_stat ADS moved with the file (20 bytes).
• An exclusive [IO.File]::Open(h, 'Open', 'ReadWrite', 'None') succeeds, so no process holds a handle on it.
• Defender real-time protection is off, so AV interference is ruled out.

So the state that goes wrong appears to be the backend's in-memory inode state, not the host file or the guest's caches.

Tried every mount option: stat-virt=strict, relaxed and off, plus host-perms=mirror,uid=1000,gid=1000. All fail the same way.

Impact: git cannot work on a Windows bind mount, because it writes a lock file and renames it over the original. git init and git clone fail with:

warning: unable to access '/workspace/gitrepo/.git/config': I/O error
fatal: unknown error occurred while reading the configuration files

The same commands work on the guest's own rootfs.

Possibly relevant code (v0.7.2), from reading the source rather than debugging, so these are leads, not a confirmed cause:

• passthroughfs/windows/ops.rs:180 (rename) → remove_ops.rs:99 (rename_inode_path). Every later op resolves files through the cached InodeData.path, so a stale entry here would produce exactly this "broken until restart" behaviour.
• remove_ops.rs:110: cached descendants of a renamed directory are only re-pathed when owned_checkpoint is set. That fits the mv d1 d2; cat d2/in failure on a plain bind mount.
• dir_ops.rs:88-110: dir_entries returns early on the first failing child, which would explain one broken entry making the whole directory appear empty.
• mod.rs:726 (host_error): unmapped Windows errors become EIO, which hides the underlying Windows error. Logging the raw error there would probably pinpoint this quickly.
• The existing heartbeat_style_rename_keeps_source_inode_usable test renames host-created files using the fs_for config. The runtime builds bind mounts differently (runner/vm.rs:2290: external_checkpoint: Some(..), no_symlink_root: true), and the failing case here is a guest-created file.

Possibly related: #1559 (hard links on bind mounts). Hard links also fail on this host (ln g hard → I/O error), and symlinks created in the guest show up as 1-byte regular files on the Windows side.

[albertsikkema-elix]

Root cause

rename_inode_path (crates/filesystem/lib/backends/passthroughfs/windows/remove_ops.rs) re-paths cached inodes with:

let path = new_path.join(path.strip_prefix(old_path).expect("selected descendant"));

For the renamed entry itself, strip_prefix returns an empty path, and PathBuf::join("") appends a trailing separator. The inode's recorded path becomes ...\h\. Every later open or stat of that inode then goes through safe_metadata_under_root, where Windows resolves h\ as a directory and returns ERROR_DIRECTORY (267). host_error has no mapping for 267, so the guest sees EIO.

The by_path lookup still finds the entry, because Path equality ignores trailing separators, so the bad path never gets corrected. That's why it persists until the sandbox restarts. dir_entries then fails on that child, which makes the whole directory list as empty.

Backtrace of the failing call (from the existing test heartbeat_style_rename_keeps_source_inode_usable, with a debug print in host_error):

host_error: raw=Some(267) kind=NotADirectory
  windows::host_error
  windows::safe_metadata_under_root
  PassthroughFs::safe_metadata
  PassthroughFs::inode_metadata
  PassthroughFs::do_open

A second, related issue: cached descendants of a renamed directory are only re-pathed when owned_checkpoint is set, so on a plain bind mount mv d1 d2; cat d2/in fails with ENOENT.

Existing tests fail on Windows at v0.7.2

On this host, two existing tests fail on unmodified v0.7.2, which suggests the Windows passthrough tests aren't running in CI:

• heartbeat_style_rename_keeps_source_inode_usable: EIO on open after rename
• ads_metadata_follows_rename_without_sidecar_move: EINVAL

Fix

--- a/crates/filesystem/lib/backends/passthroughfs/windows/remove_ops.rs
+++ b/crates/filesystem/lib/backends/passthroughfs/windows/remove_ops.rs
@@ -102,27 +102,22 @@ impl PassthroughFs {
         let mut inodes = self.inodes.write().unwrap();
         let replaced = inodes.by_path.remove(new_path);
+        // Every cached inode resolves host paths through its recorded path, so the
+        // renamed entry and any cached descendants of a renamed directory must all
+        // be re-pathed, owned or not. An unrelated destination inode keeps its
+        // retained pin.
         let moved = inodes
             .by_path
             .iter()
-            .filter(|(path, _)| {
-                path.as_path() == old_path
-                    || (self.cfg.owned_checkpoint.is_some() && path.starts_with(old_path))
-            })
+            .filter(|(path, _)| path.starts_with(old_path))
             .map(|(path, data)| (path.clone(), data.clone()))
             .collect::<Vec<_>>();
         for (path, data) in moved {
             inodes.by_path.remove(&path);
-            // Owned state records current child paths, including cached descendants of
-            // a renamed directory. An unrelated destination inode keeps its retained pin.
-            let path = new_path.join(path.strip_prefix(old_path).expect("selected descendant"));
+            let path = rebase_path(&path, old_path, new_path);
             let canonical = data.path();
             if canonical.starts_with(old_path) {
-                *data.path.write().unwrap() = new_path.join(
-                    canonical
-                        .strip_prefix(old_path)
-                        .expect("selected descendant"),
-                );
+                *data.path.write().unwrap() = rebase_path(&canonical, old_path, new_path);
             }
             inodes.by_path.insert(path, data);
         }
@@ -135,3 +130,21 @@ impl PassthroughFs {
         }
     }
 }
+
+/// Move `path` from under `old_path` to under `new_path`.
+///
+/// `path == old_path` must yield exactly `new_path`: `new_path.join("")` would
+/// append a trailing separator, which Windows then resolves as a directory and
+/// fails every later open or stat with `ERROR_DIRECTORY`.
+fn rebase_path(path: &Path, old_path: &Path, new_path: &Path) -> PathBuf {
+    let relative = path.strip_prefix(old_path).expect("selected descendant");
+    if relative.as_os_str().is_empty() {
+        new_path.to_path_buf()
+    } else {
+        new_path.join(relative)
+    }
+}

Also recommended, so this class of error is no longer hidden as EIO (windows/mod.rs):

+const ERROR_DIRECTORY: i32 = 267;
 ...
         Some(ERROR_NOT_SAME_DEVICE) => LINUX_EXDEV,
+        Some(ERROR_DIRECTORY) => LINUX_ENOTDIR,

Verification

Unit tests (cargo test -p microsandbox-filesystem --no-default-features --lib, Windows 11 host):

• Both previously failing rename tests now pass. I added three more tests that replay the guest's FUSE call sequences (echo > f; mv f h; cat h; ls, git's lock-then-rename over config, and a directory rename with a cached child). Each runs against both fs_for and a config matching runner/vm.rs for --mount-dir. All five pass.
• Full crate: 82 pass, 2 fail. The two failures, owned_restore_recovers_sidecar_aliases_before_any_new_lookup and owned_windows_namespace_is_private_and_preserves_guest_symlinks, fail identically on unmodified v0.7.2, so they're unrelated to this change.

End to end: a patched msb release build, run from PowerShell with an isolated MSB_HOME, on a C:\ bind mount, alongside the stock v0.7.2 on a fresh folder:

Check	v0.7.2	Patched
echo a > f; mv f h; cat h; ls	I/O error, total 0	a, h listed
mv -f over existing file	I/O error	ok
mv d1 d2; cat d2/in	No such file or directory	ok
git init + git config	.git/config: I/O error	ok
git clone --depth 1 https://github.com/git/git.git	rc=128	rc=0, clean git status

Note: I built with the x86_64-pc-windows-gnu toolchain (Rust 1.98.1 + MinGW), not MSVC. The fix is toolchain-independent, but I haven't verified it on an MSVC build.

Let me know if you want me to open a PR.

[toksdotdev]

hey @albertsikkema-elix, thanks for tracking this down and for the proposed fix. i'm able to repro.

yes, please open a PR. 🙏🏽