Mac OS X Hidden Files & Directories
||These files are created on volumes that don't natively support full HFS file
characteristics (e.g. ufs volumes, Windows fileshares, etc). When a Mac file
is copied to such a volume, its data fork is stored under the file's regular
name, and the additional HFS information (resource fork, type & creator codes,
etc) is stored in a second file (in AppleDouble format), with a name that
starts with "._". (These files are, of course, invisible as far as OS-X is
concerned, but not to other OS's; this can sometimes be annoying...)
||This file in created by the Finder to keep track of folder view options,
icon positions, and other visual information about folders. A separate
.DS_Store file is created in each directory to store information about that
directory, so you'll find them appearing all over the directory tree, in
pretty much every folder you've visited with the OS X Finder.
||Used to store files & folders from the boot volume that a particular
user has thrown in the trash, but that haven't been erased yet.
||Used to store metadata indexes and indexing rules for Spotlight (version
1.00 apparently). Only created under Mac OS X 10.4.
||On volumes other than the boot volume, a .Trashes folder is used to
hold files & folders that've been put in the trash but not yet deleted. Since
each user has their own personal trash can, subfolders are created under .Trashes
for different users, named according to their user ID number. For example, if
user #501 throws something on a volume named "Data" into the trash, it'd be moved
to a directory named /Volumes/Data/.Trashes/501/.
Permissions on this folder are set so that you can only access a trash can
if you can guess the users' ID -- that is, you cannot view a list of which
users actually have trash cans in existance. If you're trying to free disk
space, this can make it rather tricky to find & delete the files in other
users' trash cans...
||This contains a list of files for the Finder to hide -- it's one of
three ways a file can be made invisible in OS X.
This file is semi-obsolete -- i.e. it does not exist in a standard
installation of Mac OS X 10.4, but the Finder will still respect it
if it exists...
||Used to track commonly-used small files so their position on disk can be
optimized (a process called
hot file clustering").
||This pseudo-directory is used to access files by their ID number (aka inode
number) rather than by name. For example, /.vol/234881034/105486 is file #105486
on volume #234881034.
||Used to handle "quasi-static" mounts of network volumes under OS X 10.1.
Under most unixes, if a network volume is statically mounted on a client,
it's mounted somewhere in the file system, so it looks shows up like a
normal directory. Under OS X 10.1, a statically-mounted network volume will
actually be mounted in /automount, and a symbolic link pointing to it will
be placed where the volume would normally be mounted, thus emulating the
(Compare this with how "network" mounts are handled via
||This is one of several places where unix-style
binaries (that is, programs, or command-line commands)
are kept. The programs in /bin include the more common and fundamental
things that are used from the unix command line (e.g. ls and
rm), as well as several shells (the programs that provide the
command line itself).
The other places where similar files are stored are /sbin, /usr/bin, /usr/sbin,
and possibly /usr/local/bin, /usr/local/sbin, and maybe even
~/bin/powerpc-apple-macos; collectively, these can be thought of as the
command line's equivalent of /Applications.
||(This is actually stored in /private/cores; /cores is really just a symbolic
Under some conditions, when a program crashes, it'll "dump core" (essentially,
store a copy of the program state at the time it crashed) into this directory.
This is really only useful for programmers trying to debug their own programs.
||This directory contains what're technically known as device special files.
These are not really files in the usual sense, they're more like placeholders
that the system uses to keep track of the devices (disks, keyboards, monitors,
network connections, etc) attached to it.
||(This is actually stored in /private/etc; /etc is really just a symbolic link.)
On a typical unix system the /etc folder will contain all the configuration
files for a system, including both documents specifying config information
as well as scripts for actually performing various configuration tasks. On
OS X, some of the config information stored here is overridden by NetInfo or
other directory services, but the /etc files still exist.
||If Disk Utility or fsck discover "orphaned" files (i.e. files that exist, but
aren't actually in any directory), they'll be placed here.
||This is the "real" location of the Network item that appears at the Computer
level in the finder. It provides a place to attach network-wide resources and
server volumes. Under OS X 10.1, network resources actually tend to get
mounted in /private/Network, and symbolic links
to them created in /Network.
In OS 10.3, various network resources (mainly servers) appear dynamically in
/Network (thanks to some virtual filesystem magic).
|The Mach kernel (which runs at the very core of Mac OS X), along with a
couple of shortcuts for getting at it in various ways.
||In OS X certain root level directories are actually symbolic links (similar
to aliases) to directories in /private. Examples are /cores, /etc, and /var
which are respectively linked to /private/cores, /private/etc, and /private/var.
/private also contains a directory of drivers for certain peripherals.
||Used to handle "network" (non-static) mounts of network volumes under
OS X 10.1. Under previous versions, network mounts were mounted in
/Network, but in 10.1 they're actually mounted in
/private/network, and a symbolic link is placed in
/Network pointing to the actual mount point.
(Compare this with how "quasi-static" mounts are handled via
||The /sbin directory is like /bin except it contains binaries that are
specifically used for system administration (e.g. mount and
||(This is actually stored in /private/tmp; /tmp is really just a symbolic link.)
Programs that need temporary space on the hard disk are usally set up to write
temporary files to the /tmp directory
(although some use /var/tmp instead).
||The /usr directory contains many subdirectories that have binaries and
files specifically of use to the normal (unix)
||Another place where unix binaries are kept.
||Libraries available for use by progrmming on Mac OS X. Unless you install
the Developer Tools, this'll be mostly empty.
Note that this has no relation to Mac OS X's various "Library" directories."
||Holds various daemon programs, system maintenance scripts, and other unix-style
programs that usually aren't run directly by humans.
||As in most unixes, this directory is used to store local customizations and
additions to the standard OS installation (e.g. /usr/local/bin would be likely
to hold unix binaries added by the system administrator).
This directory can be thought of roughly as the unix equivalent of Mac OS X's
local library. In the standard install of Mac OS X it is (not surprisingly)
Note: As of OS X 10.2, these directories are no longer in the default search
path for command-line executables; as a result, anything installed here will not
be useable without taking extra steps of one sort or another.
||Yet another place where unix binaries are kept.
||Contains various data and text files that can, in principle, be shared by
multiple architectures (a distinction which makes a lot more sense under
other flavors of unix than it does under Mac OS X).
||Contains boot loader programs for (potentially) various computer architectures.
In the installs I've looked at, this is simply a duplicate of the BootX loader
(also found in /System/Library/CoreServices/BootX); I'm not sure why both
copies are needed.
||(This is actually stored in /private/var; /var is really just a symbolic link.)
Sometimes processes controlled by the operating system need a place to store
variable files. Processes like printing and programs
that store log files will use subdirectories in the /var directory to store
It also holds a fair bit of configuration information (especially in /var/db).
||Used to store backups of critical system information (mainly, the nightly
dumps of NetInfo databases).
||Holds various databases of system information. The most notable are the
NetInfo databases (stored in /var/db/netinfo), shadow password files (in
/var/db/shadow/hash), and the system's network configuration database
(/var/db/SystemConfiguration/preferences.xml - although it moved to
/Library/Preferences/SystemConfiguration/ in 10.3), which together store
much of the system and network configuration information that a
traditional unix admin would expect to find in /etc, and a Mac OS 9
admin would expect to find in System Folder:Preferences.
||This is where many of the system event logs are kept (others are kept in
||The root (superuser) account's home directory. Note that this directory
will exist even if you haven't enabled the root account.
||Stores various status information about processes (especially daemons)
running on the system.
||A place for programs to store temporary data, just like /tmp. Some programs
use one, some use the other, so Mac OS X provides both.
||Used to store the swap files for Mac OS X's virtual memory.
||Holds information about various applications' virtual memory
||The /Volumes directory is the mount point for all of the drives (other than
the boot volume) connected to the system. The Finder hides the Volumes directory
itself, but displays its contents at the Computer level.
Mac OS 9 Invisible Files & Folders
If you dual-boot your computer into Mac OS 9 as well as OS X, you'll find that
OS 9 creates additional invisible files and folders mixed in with OS X's. Here are
some of the more common examples:
||Used by OS 9's personal file sharing to keep track of which folders are
shared, and what their protections are (note that this is completely
unrelated to OS X file sharing settings and permissions).
|Cleanup At Startup
||Contains files created by Mac OS 9 applications and installers that need
to be deleted the next time OS 9 starts up.
|Used in Mac OS 7 through 9 to keep track of known document types, icons,
and which Applications can open what document types.
||The Mac OS 9 desktop folder; Mac OS X allows you to see its contents using
an alias on the Mac OS X desktop, but if you look for it directly, you won't
Note: only the Desktop Folder on the Mac OS X boot volume is invisible; any
other volume's Desktop Folders will be fully visible in the finder.
|Network Trash Folder
||Used by OS 9 filesharing clients to temporarily store trashed files. This
folder will be created in the shared folder (aka share point), and although
the OS 9 client will attempt to empty its contents before disconnecting, the
folder itself will remain.
||Used by Mac OS 9 to keep track of whether the computer shut down cleanly
||Used by Mac OS 9 applications for temporary storage.
||Stores indexes for Sherlock's Find By Content capability.
||A place for the Finder to hide various info (e.g. the desktop printer
||Anything that is put in the OS 9 trash is found in this directory after
booting into OS X.
||This is where OS 9 keeps its virtual memory backing storage, and it gets
left lying around after you boot into Mac OS X. If you want to recover the
disk space, go ahead and delete it.
When you enter a command on the Mac OS X command line, there are up to 7 different
directories where it looks for the corresponding program. Why so many, you might
ask? Well, they are organized by several different characteristics, and since
there are many possible combinations of those characteristics... it winds up being
a lot of different categories of programs. There are 6 directories that fit a
fairly consistent pattern, and one that doesn't quite fit; let me discuss the 6
First distinction: "bin" vs. "sbin". The 6 consistent directories come in
matching pairs, named "bin" and "sbin". The "bin" version contains general-use
programs, while the "sbin" version contains programs that're generally only used
for system administration. The distinction is somewhat arbitrary (for example,
the IP ping utility is in an sbin directory, but the AppleTalk version is in a
bin directory), and programs in sbin are accessible to all users (although they
often will refuse to perform unless run by an administrator, or sometimes root).
Second distinction: / vs. /usr/ vs. /usr/local/. Each of these directories can
contain bin and sbin subdirectories. Most programs are kept in the /usr/ version.
Some of the more critical, core programs (especially those that're required during
the boot process) are kept in the / directories instead. The reason for this is
that it's possible to keep /usr on a file server rather than needing a separate
copy on every computer on the network. But if this is done, the client computers
need to be able to get to the point where they can connect to a server without
having access to anything in /usr; programs that absolutely need to be available
have to go in /bin or /sbin. Finally, programs that're installed "locally" (i.e.
by a system administrator, rather than by Apple as part of the standard system
install) go in /usr/local/. If you look there on a standard OS X system, you'll
find /usr/local totally empty (/usr/local/bin and /usr/local/sbin don't even exist).
Note: in 10.2, /usr/local/bin and /usr/local/sbin were removed from the default
search path, which renders them fairly useless...
Finally, there's an idiosyncratic directory that doesn't fit the pattern of
bin/sbin pairs: it's the user's personal bin directory, named
~/bin/powerpc-apple-macos (which doesn't exist unless you take the trouble to create
it). Why such an unweildy name? Well, the idea is that your home directory might
be shared across several different computer architectures. It might, for example,
live on a server, and be accessed whenever you log into any Mac OS X, Linux, Solaris,
... etc computer on the network. Generally, a binary program will not work on more
than one of these architectures, so you want different binaries available to you
depending on precisely which computer you're using at the moment. This was removed
from the default search path in 10.1, so is now only of historical interest.
In Mac OS X, there are three different ways a file or directory can be made
invisible in the finder: it can have the "invisible" attribute set (as in older
Mac OS systems), its name can start with "." (as in other unix systems), or its
name can be listed in the /.hidden file. Many of the files
and directories listed above are actually invisible for multiple reasons (e.g.
/bin is listed in /.hidden, as well as having its invisible attribute set).
Note that OS X only respects the .hidden file on its boot volume, so if you
boot from another disk, several normally-hidden files will suddenly be visible.
Also, since Mac OS 9 (and older versions) only recognize the invisible flag, even
more of these files (mainly /.vol, /mach, /mach.sym, and sometimes .DS_Store) will
be visible when you boot into Mac OS 9.