看样子还有较为深处的原因，不过我提到的msys2那次似乎并没有python（不排除使用了python组件），其他的同样类型问题也不全是python的原因。我其实想说的是，开发者有时无法兼顾全部，比如像符号链接这种不被注意的功能（Windows确实大量使用了符号链接，但开发者有可能只是适配了这些默认的符号链接，而并非对符号链接功能进行适配，用户建立的符号链接并不一定被识别）。特别是移植或者模拟类软件，仅就文件系统的差异便已经占据了大部分精力。
我感觉也没怪罪win或者linux，我觉得更多在我自身的问题。Linux移植或者仿真类软件有时并不适合折腾或者搞一些骚操作，他们的作用更多是日常使用或者应急。这也就是我为什么建议Linux爱好者去Linux，win可以折腾，但如果是linux式的折腾，还是不要去难为移植开发者和自己了。
我觉得我更想说的是。win可以折腾，但如果是linux式的折腾，还是不要去难为移植开发者和自己了。
想起了一篇文章，讲的是 WSL 下删东西可以绕过 Windows 的系统保护
跨平台和移植应用往往没法兼顾所有平台，特别是在缺乏可靠测试的情况下，bug无法避免的。就像bleachbit，这个软件并非移植，而是使用了python进行跨平台，python库函数对于不同os的适配是有坑的。尽管开发者已经注意到了windows符号链接的问题并进行了针对处理，但处理得不够完善，还是出了bug，更致命的是测试也存在问题，使得这个bug只能靠用户来反馈。
出现这种事故，究其原因可能是缺乏风险防范意识，最终出现不可预知且无法挽回的后果。如果在使用bleachbit进行清理前，进行预览确认所有操作，是大概率能避免删错文件的。
3 个赞
这不算绕过保护吧，权限不足 WSL 也删不了，比如 reddit 上有人执行了后只删掉了个人文件，对系统文件没什么影响，能正常开机；权限足够的话 Windows 一样可以把系统删到崩溃，YouTube 有人删了 C:\Windows 后不止无法开机，安全模式和重置系统都挂了。
正解，这是Python的遍历机制的问题。正常来说，删除目录的操作，本质上应该提交给操作系统来管理维护文件链接的相关属性，而不是由软件直接操作。
另外真要对付垃圾文件生成，直接link到ramdisk，开机bat建立文件夹，每次关机就自动清理了不比用清理软件省心？
所以msys2也用了python？
我觉得不只是python的原因也是msys2的rm命令导致过递归的，但msys2的组件基本都是mingw编译的，应该不是python。
Cygwin体系下的东东两头不靠又不是一天两天了，它在哪头出问题都都怪不了平台，只能说想要两头兼容但是总有例外~
而且我觉得你应该谴责的是清理软件本身的行为不一致性，而不是mklink产生的软硬链接~本身来说软链接操作，针对的对象就应该是链接本身，由操作系统来进行路径的转译，而不是软件本身直接溯源到源文件。除非用户强行选择。这一点上我用过的Freesync，DupClener等都是有明确的用户指示的
一直在用linux，不過沒有分享，等著看你的經驗分享。
我認為與其分享「用linux的經驗」，不如說在linux系統中，用某些應用軟體，去實現甚麼事情。
已经开了新帖了:
数据。。。 刚删的话，数据恢复应该问题不大啊。。。
没被覆盖的话， 大概率能找回的吧？
只用junction, 还没研究过mklink
bleachbit…删前可以预览的啊…怎么可以相信自动清理呢…
你是真的勇士，这么折腾把自己的数据给折腾没了，我从来没有尝试过在windows下复制linux的操作
确实如此。。。应该自动备份才对。
powershell好繁琐，还是mklink来得精简。
从XP的junction用到7的mklink（10也用milink，只是目前7依旧是主力），一直用的是/j参数，也没想到会有这种隐患在。不过从描述中，感觉问题是出在清理软件，前面楼层也基本是如此判定的。
感谢楼主的分享，至少以后用清理的软件要谨慎了。不过我也如同 @haitao ，一般是直接删除的。
我也是认为楼主对 rm -fr 的理解不对。问题不是出在 mklink 里面，而是出在楼主对删除命令不理解，mklink /d 命令和 rm -fr 是不一样的。即使是 linux 里面，也需要非常特别地对待符号连接，硬连接，现在 linux 还多了一种 copy on write 或者目录的 snapshot，都是各不一样的。
加大硬盘，多开虚拟机，做好隔离在虚拟机里面折腾
确实如此，尤其删除之类的操作，要对命令下去会产生什么后果有充足的了解。
比如重复删除软件Duplicate Cleaner Pro就会有一些必要的提醒。