Windows: EXDEV cross-device link not permitted on same folder atomic rename

[yanxin20000908]

PS C:\Users\yanxzin> npx @deepseek-ai/dsh web
npm notice run npx
npm notice run dsh web
file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1187
throw new Error(${binName}: ${stage}: ${detail}${stack}, { cause });
^

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): failed to apply loader entry workspace (@deepseek-ai/dsh-workspace): EXDEV: cross-device link not permitted, rename 'C:\Users\yanxzin.dsh\storages.d3669224-c900-49f8-a758-ad593aebde15.tmp' -> 'C:\Users\yanxzin.dsh\storages\workspace.json'
Error: EXDEV: cross-device link not permitted, rename 'C:\Users\yanxzin.dsh\storages.d3669224-c900-49f8-a758-ad593aebde15.tmp' -> 'C:\Users\yanxzin.dsh\storages\workspace.json'
at async rename (node:internal/fs/promises:785:10)
at async writeAtomic (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-storage-json/lib/index.js:35:3)
at boot (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js:1187:9)
at async runProfile (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/lib/profile-boot-DG5t9aNs.js:247:14)
at async file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/lib/bin.js:133:3 {
[cause]: Error: failed to apply loader entry include (cordis:include): failed to apply loader entry workspace (@deepseek-ai/dsh-workspace): EXDEV: cross-device link not permitted, rename 'C:\Users\yanxzin.dsh\storages.d3669224-c900-49f8-a758-ad593aebde15.tmp' -> 'C:\Users\yanxzin.dsh\storages\workspace.json'
at updateError (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/cordis-plugin-loader/lib/index.js:299:9)
at Entry._init (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/cordis-plugin-loader/lib/index.js:519:10) {
[cause]: Error: failed to apply loader entry workspace (@deepseek-ai/dsh-workspace): EXDEV: cross-device link not permitted, rename 'C:\Users\yanxzin.dsh\storages.d3669224-c900-49f8-a758-ad593aebde15.tmp' -> 'C:\Users\yanxzin.dsh\storages\workspace.json'
at updateError (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/cordis-plugin-loader/lib/index.js:299:9)
at Entry._init (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/cordis-plugin-loader/lib/index.js:519:10) {
[cause]: Error: EXDEV: cross-device link not permitted, rename 'C:\Users\yanxzin.dsh\storages.d3669224-c900-49f8-a758-ad593aebde15.tmp' -> 'C:\Users\yanxzin.dsh\storages\workspace.json'
at async rename (node:internal/fs/promises:785:10)
at async writeAtomic (file:///C:/Users/yanxzin/AppData/Roaming/npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-storage-json/lib/index.js:35:3) {
errno: -4037,
code: 'EXDEV',
syscall: 'rename',
path: 'C:\Users\yanxzin\.dsh\storages\.d3669224-c900-49f8-a758-ad593aebde15.tmp',
dest: 'C:\Users\yanxzin\.dsh\storages\workspace.json'
}
}
}
}

Node.js v24.16.0

[argszero]

The stack already tells us this is NOT a plain "tmp on another device" case — and that narrows the root cause sharply.

Source facts (rc.8):

writeAtomic (packages/storage/storage-json/src/atomic.ts:24-40) writes the temp file in the same directory as the target (join(dirname(path), \.${randomUUID()}.tmp`), line 25), then rename(tmp, path)(line 34). Your error shows exactly that: both.d3669224-….tmpandworkspace.jsonare insideC:\Users\yanxzin.dsh\storages`. libuv maps the rename to MoveFileExW(..., MOVEFILE_REPLACE_EXISTING), and a same-directory rename on the same volume cannot return EXDEV. So the volume that C:\Users\yanxzin\.dsh\storages\ logically sits on must resolve to a different device through some indirection. The usual culprits, in order:

1. A reparse point (junction/symlink) on the path — e.g. C:\Users\yanxzin\.dsh (or a parent) is a junction to another volume (common when users move profile data to D:). MoveFileExW resolves through the reparse point and sees two devices.
2. Known Folder Move / OneDrive redirection of C:\Users\yanxzin — the displayed path is logical; the physical volume differs.
3. Enterprise security software (your environment has EDR-type agents) hooking MoveFileExW and failing the call — though they usually return ACCESS_DENIED, not EXDEV.

Two offline checks that pin it down:

# Is any component of the path a reparse point?
dir "C:\Users\yanxzin" /AL
fsutil reparsepoint query "C:\Users\yanxzin\.dsh" 2>&1

# Which volume actually hosts the storage dir (physical, not logical)?
(Get-Item "C:\Users\yanxzin\.dsh\storages").Target
fsutil volume diskfree C: 2>&1 | Select-Object -First 3

If a junction shows up, that is the answer — Windows reports the rename as cross-device even though both paths display under C:\.

Product-side fix (independent of the user's setup): writeAtomic should degrade gracefully — on EXDEV (and EPERM/EACCES from AV locks) fall back to copyFile(tmp, path) + rm(tmp) instead of throwing. The rename fast path stays for the normal same-volume case (atomicity preserved there); the fallback trades a tiny non-atomic window for being able to boot at all in redirected-profile setups, which is strictly better than a hard boot failure. Same seam would also cover the analogous dsh-session persistence writers if they use the same pattern.

Happy to expand the fallback sketch into a concrete patch proposal if useful.