Can't rm directory symbolic link

[kouhe3]

I got this error message when running rm -rf node_modules:

rm.cmd: cannot remove '.\opencode\node_modules.bun@aws-sdk+core@3.974.11\node_modules@aws\lambda-invoke-store': Permission denied

These folder types are SYMLINKD.

[a-rookie-of-C-language]

Windows 的 SYMLINKD 要用目录删除 API 删除。原来 rm -rf 递归入口碰到 symlink 就走 remove_file()，对目录 symlink 会触发 Permission denied。

[starfishpatkhoo]

Yep, I can confirm this bug in coreutils 2026.6.16. Here's an easy way to reproduce this bug, in an Administrator prompt:

C:\> cd \TEMP
C:\> coreutils mkdir realdir
C:\> coreutils mkdir test
C:\> coreutils ln -s realdir test\softlink
C:\> coreutils rm -rf test
rm: cannot remove 'test\softlink': Permission denied

If the soft link was to a file instead of a directory, everything works as expected.

[starfishpatkhoo]

I wanted to add that although it says it is a "permissions" problem, this problem happens no matter if you used sudo/gsudo or not, or if you have Developer Options enabled or not. The error message, while technically correct, is misleading in this instance.

[Uarz]

The rm implementation lives in the deps/coreutils submodule, which is Microsoft's fork microsoft/uutils-coreutils (a fork of the community uutils/coreutils). That Microsoft fork has issues and pull requests disabled, so I opened the fix upstream at uutils/coreutils#14159.

The fix routes directory symlinks encountered inside remove_dir_recursive through std::fs::remove_dir (RemoveDirectoryW) instead of std::fs::remove_file (DeleteFileW), matching how the top-level remove already handles directory symlinks. This makes rm -r over a tree containing a directory symlink succeed instead of failing with Permission denied.

Once it lands upstream, the submodule pointer here can be bumped in a follow-up.