![Win 10 Pro x64:命令行挂在“dir /s”管理员上](https://linux22.com/image/1616161/Win%2010%20Pro%20x64%EF%BC%9A%E5%91%BD%E4%BB%A4%E8%A1%8C%E6%8C%82%E5%9C%A8%E2%80%9Cdir%20%2Fs%E2%80%9D%E7%AE%A1%E7%90%86%E5%91%98%E4%B8%8A.png)
使用 Win 10 pro x64 (1909) 独立版(不是域的一部分),具有充足的 CPU 和 RAM 资源。这不是虚拟机或容器,而是裸机工作站。C:是 HDD,1.5 TB,已使用约 400 GB。
在以管理员身份运行的 CMD.EXE 窗口中,当我使用dir /s patternToMatch
搜索文件(始终从根目录开始)时,内部目录命令找到第一个匹配的文件(如果有的话),然后永远无法完成。无论我使用什么模式,都没有关系。
它似乎挂了。我可以用 Control-C 中断它。每次都是这样。过去,在装有早期版本的 Win 10 的工作站上,它运行正常。
该模式可以是单个文件名,没有通配符或特殊字符,并且症状似乎不会随着模式而变化。
将 DIRCMD 环境设置为 /s 不会改变症状。
屏幕上没有显示任何错误或消息。我等了几个小时。
我在 eventvwr 中看不到任何可能相关的内容。
所有文件系统都是 NTFS。
工作站有另外 4 个 NVME 驱动器(其中只有 2 个对 Windows 可见,即 D: 和 E:),并且DIR /s
从根目录发生时 D: 也会出现相同症状。但 E: 驱动器没有出现症状。
如果我从那里cd c:\users
发出dir /s
,则症状会重复出现。但如果我cd c:\users\me
运行,dir /s
则它会找到文件(如果存在)并且不会挂起。
没有报告硬件错误。机器具有制造商提供的最新 BIOS 和固件。
有什么建议么?
更新:
非管理员用户执行搜索时症状没有改变
在 D: (nvme) 上运行 CHKDSK /F 并强制卸载,然后
dir /s
使用当前目录运行D:\
,症状没有改变,仍然挂起。启动时在 C: 上运行 CHKFSK,需要重新启动,但之后症状没有变化。
我发现在三个 Windows 驱动器 C:、D: 和 E: 中,只有 C: 和 D: 受到此症状的影响。因此,C: 和/或 D: 上的文件系统中一定存在与 chkdsk 无关的因素,而这些因素会影响此症状。我将检查连接点。
答案1
导致该症状的直接原因是 C:\ProgramData\Docker(在 HDD 上)与 D:\ProgramData\Docker(在 NVME 上)是连接点。
清除 Docker-Desktop 缓存并卸载 Docker Desktop,然后删除此连接即可解决此问题。因此,该dir /s
命令现在可正常运行。
我不知道这种行为是否是设计使然。
似乎 Windows 版 Docker Desktop 只能与 C:\ProgramData\Docker 一起使用,并且将其作为连接点(利用 NVME 速度进行 docker 构建操作)会产生不良的副作用。