Hi, I ran into an issue on Windows when trying to open a drive root as a checkout workspace.
For example, my config allows both D:\ and E:\, and opening normal subdirectories works fine:
E:\MinerU
D:\Book-Mathematical-Foundation-of-Reinforcement-Learning
E:\Obsidian仓库\RL学习
But opening the drive root itself fails:
open_workspace
path = "D:\\"
mode = "checkout"
The error is:
EPERM: operation not permitted, mkdir 'D:\'
Same thing happens with E:\:
EPERM: operation not permitted, mkdir 'E:\'
I checked the local source a bit and it looks like this may come from openCheckoutWorkspace() in src/workspaces.ts:
const root = assertAllowedPath(path, this.config.allowedRoots);
await mkdir(root, { recursive: true });
const rootStats = await stat(root);
For normal folders this is fine, but for a Windows drive root like D:\ / E:\, calling mkdir(root, { recursive: true }) seems to fail with EPERM.
I think it would be better to check whether the path already exists before calling mkdir. For example:
- if the path already exists and is a directory, just continue
- if it does not exist, then call
mkdir
- if drive roots are not intended to be supported, return a clearer error message earlier
Right now the confusing part is that the drive root passes the allowed roots check, but then fails later during workspace initialization.
This matters because on Windows it is useful to allow a workspace at a higher-level path, especially when there are multiple projects under the same drive.
Hi, I ran into an issue on Windows when trying to open a drive root as a checkout workspace.
For example, my config allows both
D:\andE:\, and opening normal subdirectories works fine:But opening the drive root itself fails:
The error is:
Same thing happens with
E:\:I checked the local source a bit and it looks like this may come from
openCheckoutWorkspace()insrc/workspaces.ts:For normal folders this is fine, but for a Windows drive root like
D:\/E:\, callingmkdir(root, { recursive: true })seems to fail withEPERM.I think it would be better to check whether the path already exists before calling
mkdir. For example:mkdirRight now the confusing part is that the drive root passes the allowed roots check, but then fails later during workspace initialization.
This matters because on Windows it is useful to allow a workspace at a higher-level path, especially when there are multiple projects under the same drive.