我在尝试找出计算机上哪些文件占用了最多的空间时遇到了这个问题。以下是有关机器总内存的信息,来自 Windows Subsystem for Linux (WSL) /bash
bballdave025@WORK:~$ df -h /mnt/c
Filesystem Size Used Avail Use% Mounted on
C: 239G 231G 7.8G 97% /mnt/c
请注意,我的问题不是关于如何清理空间。
我首先检查了Program Files
目录。
bballdave025@WORK:~$ du -sh /mnt/c/Program\ Files/
du: cannot read directory '/mnt/c/Program Files/Microsoft Policy Platform/authorityDb': Permission denied
du: cannot read directory '/mnt/c/Program Files/Microsoft SQL Server/130/Shared/ErrorDumps': Permission denied
du: cannot read directory '/mnt/c/Program Files/WindowsApps': Permission denied
2.5T /mnt/c/Program Files/
主要问题
我的 WSLbash
du
告诉我,在我的机器上(239GB
内存为),我的Program Files
目录占用了2.5TB可用内存的百分比239GB
。这就像我嘴里含着两品脱的水却不吞下去。(这只是为了显示大小比例——我的问题与水无关。)
顺便说一句,我没有管理员权限——无法解决sudo !!
任何问题。我将省略Permission denied
错误(将要没有真实的 sudo
),我会继续写这篇文章。另请注意,我使用的是工作电脑,因此有些东西我无法访问。
主要问题:在我的环境中,有没有一种相对简单的方法来检查磁盘使用情况,即C:
使用 Windows Subsystem for Linux 检查 Windows 驱动器上的磁盘使用情况?
次要问题:这到底是怎么回事?为什么我会收到报告说我的Program Files
目录占用的空间比我机器上现有的空间多 10 倍?
顺便一提...Windows 告诉我其Program Files
大小为4.83 GB
,这是我通过使用File Explorer
、右键单击Program Files
文件夹并选择“属性” 发现的。
我的解决方案尝试
我的第一个想法是,可能有一些符号链接或驱动器映射内容,用于公司编码软件或防病毒程序等,所以我查看了页面man
。du
我发现了以下两个标志,我认为这可能会有所帮助。
-P, --no-dereference don't follow any symbolic links (this is the default) -x, --one-file-system skip directories on different file systems
然而du -shP /mnt/c/Program\ Files/
,,,du -shx /mnt/c/Program\ Files/
甚至du -shPx /mnt/c/Program\ Files/
给了我2.5T
。就此而言,应该跟随符号链接,du -shL
。它输出2.5T
。对于我尝试过的其他可能相关的选项也是如此,du -shD
并且,对所有选项du -shH
都给出了相同的-- 。2.5T
我的下一个想法是,也许 Windows 快捷方式把事情搞乱了,所以我尝试排除它们。(我不知道此代码是否真的可以防止以下快捷方式,但我认为值得一试。)没有成功。
bballdave025@WORK:~$ du -sh --exclude=*.lnk /mnt/c/Program\ Files/
2.5T /mnt/c/Program Files/
我可以抛开偏见,尝试一些东西,<shudder> Windows Command Line </shudder>
甚至重拾我的旧PowerShell
技能。我想我甚至可以硬着头皮进入 GUI 中的每个目录File Explorer
,单击每个文件夹,选择“属性”,找到哪个子目录占用的空间最多,进入内存使用率最高的目录,然后重复单击每个文件夹……[睡觉]……
... 不过,我很想知道为什么我会得到这个奇怪的结果。当我查看时Program Files (x86)
,我得到的结果就像把一个足球(非美式)塞进嘴里一样。(再次强调,我说的是尺寸比例;我的嘴巴的体积与我的问题无关。)
bballdave025@WORK:~$ du -sh /mnt/c/Program\ Files\ \(x86\)/
11T /mnt/c/Program Files (x86)/
(我等待了 30 秒后,Windows /File Explorer
报告的大小为 22.8 GB...)
来源和尝试
从这个超级用户的回答,我想尝试检查我的情况是否
您删除的文件可能仍被某个进程打开。
bballdave025@WORK:~$ lsof -a +L1 /mnt/c/Program\ Files/
bballdave025@WORK:~$
由于没有输出,我假设我删除的文件没有被进程打开。
我也看了这个问题和答案关于du
Linux 和 Cygwin 上的不同结果。但是,该问题中描述的大小差异很小,因此我不认为该问题类似。虽然我确信
因此,当存储在不同的文件系统上时,同一组文件使用不同的磁盘大小也就不足为奇了。
我做认为使用同一套文件是一个惊喜任何当它们实际上存储在一个地方时,磁盘大小会有所不同,即使存在不同的底层方式来访问它们。
下一步
我决定在我的驱动器上创建一个文件夹C:
,放入一个小文件,然后检查文件大小是否符合预期。
bballdave025@WORK:~$ mkdir -p /mnt/c/Users/bballdave025/little_guy
bballdave025@WORK:~$ echo "This should make a small file." > /mnt/c/Users/bballdave025/little_guy/small_file.txt
bballdave025@WORK:~$ du -sh /mnt/c/Users/bballdave025/little_guy/small_file.txt
17K /mnt/c/Users/bballdave025/little_guy/small_file.txt
bballdave025@WORK:~$ du -shPx /mnt/c/Users/bballdave025/little_guy/
17K /mnt/c/Users/bballdve025/little_guy/
对于这个小文本文件来说,17KB 确实很大。如果每个字符有一个字节,那么就有 31 个字节。我不知道这个练习(创建文本文件并检查du
)是否有助于回答这个问题,但这是我努力的一部分。
我被困住了。我真的不想点击文件夹。我也想知道为什么会出现这种奇怪的行为。有什么想法吗?
系统详细信息
bballdave025@WORK:~$ uname -a | head -n 1
Linux WORK 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
bballdave025@WORK:~$ bash --version | head -n 1
GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu)
bballdave025@WORK:~$ systeminfo.exe | sed -n 's/^OS\ *//p'
Unable to translate current working directory. Using C:\Windows\System32
Name: Microsoft Windows 10 Enterprise
Version: 10.0.15063 N/A Build 15063
Manufacturer: Microsoft Corporation
Configuration: Member Workstation
Build Type: Multiprocessor Free
答案1
再生产
我刚刚尝试了与您相同的命令:du -sh /mnt/c/Program\ Files/
我的报告与 Windows 报告的内容一致。
这可能是一个错误,并且已经修补了,或者您的文件系统中存在一些我没有遇到的问题。您已经深入研究了链接/快捷方式,但也许还有一些东西被忽略了?
我确实对照Bash on Ubuntu on Windows
“WSL Legacy”进行了仔细检查,并且Ubuntu
两者都报告了相同的结果。
刚刚看到关于已报告错误,看起来提到的一切都已经修补好了