******

Since the introduction of Mac OS X, there have been more frequent reports of hard drive volumes full for reasons not known to their owners, or reports of large amounts of disk space occupied for unknown reasons. This article describes every cause of the “missing disk space problem” I have seen in these forums.

First, make sure that the apparently missing disk space problem is not the result of a disk directory error. Errors in the Volume Bitmap portion of the disk directory, which records which sectors of the disk are free and which ones are occupied by pieces of files, can cause the reported free space to be inaccurate.

To check the disk directory, use Disk Utility while booted from another volume, run fsck in single-user mode, or use a third-party disk repair utility. See Using Disk Utility and fsck for file system maintenance in Mac OS X.

If no disk directory error is found, follow this plan:

If you have either of these third-party products installed, read the relevant articles:

1. If you have used Norton Antivirus for Macintosh version 9.0, the missing disk space may be accounted for by the spacesuckingfile. The Symantec article explains how to find and delete the invisible file, and how to upgrade to a newer version to avoid having this problem later. [Problem may be back in version 10.1.]

2. If you have older Macally iShock game controller device drivers installed, please see Mac OS X 10.3.8: Free disk space disappears after updating to 10.3.8.


In most cases, there really are files occupying part of the volume, but the files are invisible in normal use of the Finder.

Using the Finder’s Go to Folder feature (in the Go menu), look at the sizes of the contents of these folders, by pasting in these pathnames:

/private/var/vm

/private/var/log

/Volumes

The /private/var/vm directory contains the swapfiles used by virtual memory. New ones are made as more data is swapped from RAM to the hard drive. The entire process of creating them begins at each reboot or restart; do not attempt to remove them yourself. Check the total size of all the swapfiles, right after you boot, and as the disk fills up. In Panther, the first two swapfiles are 64MB, then each new one is twice the size of the preceeding one (128MB, 256MB, 512MB, 1 GB) up to a maximum size of 1 GB. In Tiger, the first two swapfiles are 64 MB, the next one is 128 MB, and any additional swapfiles are 256 MB (see this screen capture showing 11 swapfiles in a Tiger system).

If you do not run the daily, weekly, and monthly maintenance scripts (either by using a utility, or by running the commands sudo periodic daily, sudo periodic weekly, and sudo periodic monthly in Terminal), the logs on the startup volume can become too large. If an error is occurring frequently and is being logged, you can have a very large file at /private/var/log/system.log. I recently saw mention of a system.log file that was larger than 40 GB. See http://docs.info.apple.com/article.html?artnum=107388 for Apple’s explanation of the maintenance scripts and what utilities you can use to run them.

The files in /Volumes should be aliases to your mounted volumes. Do not remove these aliases, because anything you do to them happens to the contents of the corresponding volumes. If you are not confident that you can explore this folder without mishap, before you begin, properly unmount any volume other than the startup volume, if the missing disk space problem affects only that volume. External FireWire drives can be disconnected after proper unmounting.

Sometimes, backup programs that cannot find an intended destination (or target) volume for a backup create a folder with the same name as the destination, and put the folder into the /Volumes directory. There are cases in which the entire startup volume has been backed up on itself, in a folder inside /Volumes. If the amount of missing space is about the size of your user folder, such a backup is likely to be the explanation. If you use Carbon Copy Cloner or another backup or cloning utility and have its preferences configured to create a backup on a schedule, and the intended destination volume is not mounted or is sleeping at the scheduled time, the backup is created in the /Volumes directory.

To check the size of the normally invisible /Volumes directory on the active startup volume, open a new Finder window. Select the startup volume in the list at the left, then choose column view (the one at the right of the three views). From the Finder’s Go menu, choose Go to Folder, and paste in:

/Volumes

The /Volumes directory becomes visible in the Finder; find its size by selecting it and typing Command I. My /Volumes directory is reported to be 12K.


Try to determine where your various caches are. There may be files left over from burning CDs or DVDs. The One Step DVD option in iDVD has been reported to leave files in the directory /private/tmp.
The backup utility Retrospect may leave a large file at /Library/Preferences/Retrospect/RetroData.tmp.

WhatSize lists both visible and invisible files and sorts the search results by size. It reports the contents of the various trash directories.

To explore the trash using Terminal:

There may be files in one or both of the Trash directories, despite an apparently empty bin in the Finder. The two directories are:

/.Trashes

at the root level of the disk and

/Users/user_name/.Trash

in your own user folder.

To see the contents of /.Trashes, open Terminal, located in /Applications/Utilities. Type:

cd /.Trashes

Press the Return key, then type:

sudo ls-lias

Press the Return key, and enter your administrative password.

Your session should look like this if your system trash is empty:

MMT3s-Computer:~ MMT3$ cd /.Trashes
MMT3s-Computer:/.Trashes MMT3$ sudo ls -lias
Password:
total 0
19 0 d-wx-wx-wt 3 root admin 102 27 Mar 2004 .
2 0 drwxrwxr-t 54 root admin 1836 26 Feb 12:56 ..
399372 0 drwx------ 2 MMT3 admin 68 27 Mar 2004 501

Now, explore your user Trash. Type:

cd ~/.Trash

Press Return. Then type:

ls -lias

Press Return.

Your session should look like this if your user Trash is empty:

MMT3s-Computer:/.Trashes MMT3$ cd ~/.Trash
MMT3s-Computer:~/.Trash MMT3$ ls -lias
total 16
377779 0 drwx------ 3 MMT3 MMT3 102 26 Feb 09:44 .
377615 0 drwxr-xr-x 38 MMT3 MMT3 1292 31 Jan 00:32 ..
3092148 16 -rw------- 1 MMT3 MMT3 6148 26 Feb 09:44 .DS_Store
MMT3s-Computer:~/.Trash MMT3$


Please see Why Defrag? for a description of the possible consequences (irreparable disk directory damage) of having any HFS+ volume too full, and the importance of having sufficient disk space that is both free and contiguous on each volume. The free space should be a minimum of 15%.

I recently went through this same exersize of trying to find where all my drive space went, I found a few applications that help with it, then I found a site that had an old school solution to finding where all the space went, it was a pretty slick little "how to" video, the site looks new but the info on it seems really good. and no its not my site..lol.. learn to mac I even sent an email to them on a topic and they made a video that covered my question... give it a shot and no its not my site..lol.. I'll list mine below for a shameless plug.

good luck

DD

trials of the switch

thanks for your help, both of you. it appears i am a bit of a dork - i had put a 160GB movie into the trash and not got rid of it!!

TWO QUICKIE TARGETED SEARCHES FOR TERMINAL

: a pair of command line search strings which might
: possibly pin down overly large items... posthaste.

The main advantage of these two scriptlets is that each should
complete execution in less than 15 seconds. (Whereas, running
a 'full' scan or a 'full' search could take several minutes each).

Ergo -- if fortune has it that the offending jumbo item happens
to be in one of the (statistically typical) locations, then -- these
scripts will zoom in on the problem area in *under* a minute.

Actually... the 'du' script below could take much longer than 15
seconds to finish, if a lot of files are found (inside /Volumes for
example). But that would also mean our search was successful!
Thus, any extra time spent would be worthwhile in that case...

code:

#1) Find files over 100 megs inside the usual suspects: 

sudo -v; sudo find -xf /.Trashes /Volumes /Library /private /Temp* \
-type f -size +200000 -print0 | sudo xargs -0 ls -lohdSr


#2) Measure sizes of the usual suspects (plus Spotlight's index): 

IFS=$'\n'; for f in /Volumes /.Spotlight* /.Trashes /Library/Logs /private/\
{var/{log,spool,db,vm,tmp},tmp} /Temp*; do sudo du -hsx $f; done; IFS=$' \t\n'

For each case above, copy the two adjacent blue lines as one and
paste them together into a Terminal.app window. If the user isn't
already validated, an admin password will be required. After both
runs are completed, save all text for the record. Results from the
file search and/or the folder scan should contain enough clues to
resolve the "missing-space" puzzle. When finished with Terminal,
press ctrl-D (or exit) to end the session, and finally command-Q.

Should those two fail to find the extra large folder or file, then
only a minute or so was "lost", and the user can proceed ahead
with more time-consuming techniques (such as sudo du -xhd1 /
or GUI apps like WhatSize, DiskSweeper, or JDiskReport, etc,).

Test them out today, just to see what "normal" is for your Mac.
Here's what their output looks like on mine...

code:

$ sudo -v; sudo find -xf /.Trashes /Volumes /Library /private /Temp* \
> -type f -size +200000 -print0 | sudo xargs -0 ls -lohdSr
Password:
-rw-rw-r-- 1 root admin - 198M Nov 18 2003 /Library/-path-edited-/Our First Snowman.mov

$ IFS=$'\n'; for f in /Volumes /.Spotlight* /.Trashes /Library/Logs /private/\
> {var/{log,spool,db,vm,tmp},tmp} /Temp*; do sudo du -hsx $f; done; IFS=$' \t\n'
 12K    /Volumes
205M    /.Spotlight-V100
  0B    /.Trashes
884K    /Library/Logs
6.3M    /private/var/log
116K    /private/var/spool
 37M    /private/var/db
 69M    /private/var/vm
216K    /private/var/tmp
 84K    /private/tmp
  0B    /Temporary Items

Note: if #1) is finding too many needed files that you feel inappropriate...
the 100 meg lower limit can be tweaked. E.g., for "500 megs and higher":

code:

sudo -v; sudo find -xf /.Trashes /Volumes /Library /private /Temp* \
-type f -size +1000000 -print0 | sudo xargs -0 ls -lohdSr

Bon voyage,

-HI-

Interesting nested parentheses in your script, Hal.

12K /Volumes
44M /.Spotlight-V100
0B /.Trashes
1.1M /Library/Logs
2.6M /private/var/log
8.0K /private/var/spool
3.9M /private/var/db
67M /private/var/vm
124K /private/var/tmp
12K /private/tmp
0B /Temporary Items

You can tell at a glance that there is no printer connected to my G4 Cube.

Sometime in the last week my disk got filled. It is a 74GB disk that typically had about 15-17GB of
data on it. DiskinventoryX says there is about 1GB available (after I deleted a lot of stuff to make
the system useable). But DiskinventoryX only shows about 17.2GB of disk usage in the files and directories.
I ran fsck in single user mode and it finds no problems. I assume my only option left is to reformat the
disk and reinstall everything. That kind of defeats the entire purpose of why I gave up on Windows
2 years ago and bought my first Mac. Of coarse my next problem is that my DVD drive can't read
my install CD. So I have to get that replaced..or go back to Windows. Any other suggestions?

Never mind. I thought I had covered everything, but I reran Hal's script and
there it was in a Library console log: a 54GB log file. I quickly removed it and
all my space came back. I wish I would have looked at the file first to see what
application was filling the log. I am now happy with my Mac again (except for the
hardware failure). Over 2 years and never re-installed the OS. In the same time
I have reinstalled Windows at least 6 times on my kids PCs.

Just finished wasting a bunch of time trying to figure out where 30G went, so I thought I should add another reason to your list of possible places: Other user accounts. When troubleshooting, I looked at the size of an old user account in the finder, and it showed 1.5G; if it had shown 0, I would have realized the problem. Running the scripts above also failed to show any files for the same reason. Unfortunately, I have permission to see only some of the files, so it was actually 31G. When I logged in to that account, I saw the rest of the files.

Thanks for your report.

I hope Hal will comment on the apparent failure of the script to find the files in the other user folder.

I haven't seen Hal around these parts for awhile. He was in Sweden and out of touch last year at this time. Maybe that's an annual pilgrimage?