I ran into my question while trying to find out which files on my computer are taking up the most space. Here's the information on the total machine memory, found from 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
Note that my question is NOT about how to clear the space.
I started by checking the Program Files
directory.
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/
The Main Issue
My WSL bash
du
is telling me that, on my machine (which has 239GB
of memory,) my Program Files
directory is taking up 2.5TB of the 239GB
of available memory. It's like I'm holding two pints of water in my mouth without swallowing. (That's just to show the ratio of sizes -- my problem doesn't involve water.)
By the way, I don't have admin rights -- no sudo !!
to solve any issues. I will leave out the Permission denied
errors (that will come without a real sudo
) as I continue to write this post. Also note that I'm on a work computer, so there are things I can't access.
Main question: Is there a relatively simple way to check disk usage in my situation, that is, to check disk usage on a Windows C:
drive using Windows Subsystem for Linux?
Secondary Question: What the heck is going on here? Why am I getting a report that my Program Files
directory is taking up 10 times more space than even exists on my machine?
By the way... Windows tells me that Program Files
has a size of 4.83 GB
, a fact I found by using File Explorer
, right-clicking on the Program Files
folder, and selecting 'Properties'
My Attempts at a Solution
My first thought was that there might be some symlinks or drive-mapping stuff for company coding software or an antivirus program or something, so I checked out the man
page for du
. I found the following two flags, which I thought might help.
-P, --no-dereference don't follow any symbolic links (this is the default) -x, --one-file-system skip directories on different file systems
However, du -shP /mnt/c/Program\ Files/
, du -shx /mnt/c/Program\ Files/
, and even du -shPx /mnt/c/Program\ Files/
gave me 2.5T
. For that matter, so did the option that should follow symlinks, du -shL
. It output 2.5T
. Same for the other, maybe-related options I've tried, du -shD
and du -shH
, gave the same -- 2.5T
for all of them.
My next thought was that perhaps Windows shortcuts were messing things up, so I tried excluded them. (I don't know if this code actually prevents following shortcuts, but I thought it worth a try.) No dice.
bballdave025@WORK:~$ du -sh --exclude=*.lnk /mnt/c/Program\ Files/
2.5T /mnt/c/Program Files/
I could leave prejudices behind and try something from the <shudder> Windows Command Line </shudder>
or even dust off my old PowerShell
skills. I guess I could even bite the bullet and go to each directory in the File Explorer
GUI, click each folder, select 'Properties', find which subdirectory takes the most space, enter the directory with the most memory usage and repeat clicking each folder ... [sleeping] ...
... However, I'm interested in why I'm getting this weird result. When I look at Program Files (x86)
, I get a result that's like stuffing a soccer ball (non-American) football in my mouth. (Once again, I'm talking in terms of the ratio of sizes; the volume of my mouth is not related to my problem.)
bballdave025@WORK:~$ du -sh /mnt/c/Program\ Files\ \(x86\)/
11T /mnt/c/Program Files (x86)/
(Windows / File Explorer
reported a size of 22.8 GB ... after I'd waited 30 seconds.)
Sources and Attempts
From this Super User answer, I got the idea to try checking that my situation wasn't
The files you removed are probably still opened by a process.
bballdave025@WORK:~$ lsof -a +L1 /mnt/c/Program\ Files/
bballdave025@WORK:~$
Since there was no output, I'm assuming that no files I removed are still opened by a process.
I also looked at this question and answer about different du
results on Linux and Cygwin. However, the discrepancies in size described in that question were minuscule, so I don't believe that the issue is similar. While I'm sure that
There is then no surprise for the same set of files to use differring [sic] disk size when stored on different file systems.
I do think that it's a surprise for the same set of files to use any differing disk size when they're really stored in one place, even if there are different underlying ways to access them.
Next steps
I decided to create a folder on my C:
drive, put in a small file, and check to see that the file size was as expected.
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 does seem big for that little-bitty text file. If we have a byte per charater, that would give us 31 bytes. I don't know if that exercise -- making a text file and checking du
-- will help to answer the question, but it's been part of my effort.
I'm stuck. I really don't want to click through folders. I also want to know why I get this weird behavior. Any ideas?
System Details
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
<shudder> Windows Command Line </shudder>
or even dust off my oldPowerShell
skills. I guess I could even bite the bullet and go to each directory in theFile Explorer
GUI, click each folder, select 'Properties', find which subdirectory takes the most space, enter the directory with the most memory usage and repeat clicking each folder ... [sleeping] ... I much prefer abash
solution (more powerful, quicker), and I'm also curious about the strange behavior.file
command reported it was an ASCII text file,ls -l
reported it was 77 bytes, and when Icat
ed it, I could see this was all true. I did not edit it or eventouch
it. And suddenlydu
stopped reporting it as 5.3E, and gave its true size. Go figure.