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) /
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
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
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)/
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.
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?
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