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/

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
  • I could leave my 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] ... I much prefer a bash solution (more powerful, quicker), and I'm also curious about the strange behavior. – bballdave025 Sep 7 '18 at 3:51
  • WSL inherit the permission (sort of) from Windows account. So if you open wsl.exe as administrator you may access ProgramFiles with Linux tools. This question is 90% superuser-ish type. – Biswapriyo Sep 7 '18 at 5:51
  • Thanks for your help. I hadn't seen the link shared by @KamilMaciorowski. <s>I'm going to delete the question from StackOverflow.</s> Actually, I'm going to see if it's possible to merge the comments from both posts. If there's a moderator who sees this, could you do this or let me know how? If it hasn't been merged/migrated by tomorrow morning, I'm going to delete the SO question. Thanks again. – bballdave025 Sep 7 '18 at 6:11
  • 2
    Looks like this bug reported a year and a half ago, then several more times (see the bottom of the page). Sysinternals has a Windows-native version of du that should work although I last tried it somewhere around Vista/Seven. – dave_thompson_085 Sep 7 '18 at 6:28
  • Good point, @KamilMaciorowski. I've already deleted the other one, because there was just one comment, and it was more of a humorous one. Thanks for helping me to understand the site and use it better. – bballdave025 Sep 7 '18 at 6:28

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.