write/edit tools fail on Google Drive Desktop virtual filesystem (Windows): SetFileSecurityW Win32 87 and link EISDIR

[rossichaves]

dsh version: 0.1.1-rc.2
OS: Windows + Google Drive Desktop (workspace on G:\Meu Drive\..., virtual filesystem with cloud placeholders)
Permission mode: tested with workspace-write and danger-full-access

Symptoms

1. write (creating a new file) fails with EISDIR: illegal operation on a directory, link '<staging-dir>\<name>.tmp' -> '<target>' — the atomic publish uses a hard link (fs.promises.link), which the Google Drive virtual filesystem does not support.
2. edit (overwriting an existing file) fails with SetFileSecurityW EIO (Win32 87): <staging-dir>\<name>.tmp — before writing, the file's DACL is copied to the staging file via Win32 SetFileSecurityW, which returns ERROR_INVALID_PARAMETER on the Drive virtual filesystem.
3. pwsh under workspace-write fails to initialize: SetNamedSecurityInfoW failed (Win32 87): grantWrite('<workspace>') — the ACL-grant step fails on the virtual filesystem.
4. Working workaround: run with danger-full-access and write files directly (PowerShell Set-Content, Python open(path, 'wb')). Read-only tools (read/grep/glob) and git work normally. Tools that write directly (Claude Code, Obsidian) work fine on the same folder.

Root cause

In @deepseek-ai/dsh-fs-local/lib/index.js, writeFileAtomic:

• ~line 485: if (platform === "win32" && mode !== void 0) await copyFileDacl(absolutePath, tempPath) → SetFileSecurityW(path, 2147483652 /* DACL + PROTECTED_DACL */, descriptor).
• ~line 500: await linkFile(tempPath, absolutePath) on the createIfAbsent (new-file) publish path.
• The internals.copyFileDacl / internals.linkFile overrides are test hooks only — there is no user-facing configuration to disable the ACL copy or the hard-link publish.

Impact

On Windows, any workspace synced by Google Drive (and likely OneDrive/iCloud) cannot use the built-in file tools at all: both creating and editing files fail. This forces a shell/Python workaround for every file operation, or abandoning cloud-synced workspaces — a very common setup (Obsidian vaults, code repos on Drive).

Suggested fix (graceful degradation)

1. Make the DACL copy best-effort: wrap GetFileSecurityW/SetFileSecurityW in try/catch; on failure (Win32 87, 5, 6) log a warning and continue — the staging file inherits the parent directory's ACL anyway.
2. Fall back when link() is unsupported: copy the staged file with open(dest, 'wx') + write + rename when link throws EISDIR/EPERM/ENOTSUP.
3. Optionally detect cloud/virtual filesystems (reparse points, offline attribute, or a quick probe) and skip ACL preservation there.

[ylwl1997]

Google Drive Desktop’s virtual FS does not support fs.link() or SetFileSecurityW, so writeFileAtomic in @deepseek-ai/dsh-fs-local always fails there — new files (EISDIR on link) and overwrites (Win32 87) are the same path. grantWrite dying on SetNamedSecurityInfoW is the ACL twin. Stock 0.1.1-rc.2 has no switch to skip those steps.

danger-full-access plus writing through pwsh/Set-Content or Python works because it bypasses the atomic publish. The durable fix is a real local NTFS/ReFS directory: copy or git clone the workspace off G:\Meu Drive\..., then open that path in DSH. Cloud placeholders (Drive / OneDrive Files On-Demand) will keep breaking hardlink publish and ACL grant.

[weijiafu14]

根因定位得很准（copyFileDacl → SetFileSecurityW 在虚拟盘上返回 Win32 87；writeFileAtomic 的原子发布用 fs.promises.link 硬链接，Drive 虚拟文件系统不支持）。而且你已经证明了那个盘本身没问题——Claude Code、Obsidian 直接写都正常，只有 DSH 的原子写序列过不去，这是很干净的对照。

关于你现在的绕法，有个安全上的取舍值得说

你的 workaround 是用 danger-full-access 跑，再用 PowerShell / Python 直接写。这能用，但代价是：为了绕开一个文件系统兼容问题，把整个会话的沙箱关掉了——从此这个 agent 的所有写操作都不受约束，而不只是 Google Drive 那部分。

有一条范围更窄的路：挂一个 filesystem 类的 MCP server，只把需要写的那些目录交给它，模型用它的写工具落文件。那个 server 是独立进程，用普通的 open/write，不走 writeFileAtomic 那套 DACL 复制 + 硬链接，所以你报的两个 Win32 错误都不会发生。

但必须说清两件事，否则就是拿一个坑换另一个坑：

1. MCP server 跑在 DSH 沙箱之外。 它的写操作不受 DSH 文件策略约束——所以这不是"回到 workspace-write 的安全等级"，而是"把写权限的范围从整机收窄到你交给那个 server 的目录"。相对 danger-full-access 是收窄了，但它是另一种信任模型，不是原来的那个。
2. 我没有在 Google Drive 虚拟盘上实测过这条。 机制上成立（普通写，没有原子发布那套动作），但 Drive 的 placeholder 语义还有别的坑（比如按需下载、稀疏文件），我不替它打包票。你要试的话先拿一个不重要的目录试。

真正的修法还是在 DSH 这边

你提的两处都很具体，而且看起来都能做成"探测到不支持就降级"：

• copyFileDacl 在 SetFileSecurityW 失败时跳过 DACL 复制而不是整个写失败（DACL 复制是锦上添花，不是正确性必需）；
• 原子发布在 link 抛 EISDIR/EPERM 时回退到 rename（虚拟盘、网络盘、跨卷都会遇到）。

这类"虚拟/网络文件系统不支持硬链接"是很常见的边界，值得作为通用兼容性来处理，而不只是修 Google Drive。我们改不了 dsh-fs-local。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。上面那条 MCP 方案用的是官方 @deepseek-ai/dsh-mcp-client 就能接，不需要装我的东西。

[398894496-arch]

Same copyFileDacl / ReplaceFileW path on stock @deepseek-ai/dsh@0.1.1-rc.2, but the volume is a Windows UNC share (\\host\share\...), not Google Drive.

• SetFileSecurityW after staging → Win32 5 (ERROR_ACCESS_DENIED). Bytes already landed; the ACL copy aborts the whole edit/write.
• Official publish of an existing file uses ReplaceFileW; the share often returns Win32 5 as well. Create-new can still work while overwrite dies.
• workspace-write ACL grant cannot plant an NTFS DACL on a network volume either (no local volume to grant on). That is a separate sandbox issue; this comment is only the write/publish path.

Suggested degradation matches this thread: skip DACL copy on UNC (and treat ACCESS_DENIED as inherit-from-share); skip ReplaceFileW on UNC and rename the staging file.

No PR (CONTRIBUTING). Workaround: https://github.com/398894496-arch/TDHarness-coding marks company-fs-unc-acl-v1 / company-fs-unc-replace-v1.

同类：公司 SMB（UNC）上是 Win32 5，不是 Drive 的 87。跳过 UNC 上的 DACL 拷贝 / ReplaceFileW 后写入能完成。