When I use nautilus to browse a directory (the specific example in this one is the /media folder) I see nothing, but when I type ls -a in the terminal it shows:


in blue. I'm aware that blue highlights are directories and the . and .. can symbolize parent and working directories, but why are they in the /media folder?

  • 2
    You said it yourself. They "symbolize parent and working directories". Why should the kernel have discretion on whether . and .. exist?
    – Cole Tobin
    Nov 11, 2015 at 3:52
  • Related: unix.stackexchange.com/questions/61984/… Nov 11, 2015 at 4:17
  • 1
    As noted below, . and .. exist in all directories. If you want to see all files in a directory except those, use ls -A instead of ls -a. Nov 11, 2015 at 15:28
  • Note that dot and dot-dot must exist in all directories to allow relative file names in a tree structure of directories. Nov 12, 2015 at 5:34

5 Answers 5


If Nautilus shows nothing and ls -a only shows . and .., then there is nothing in that directory.

Directory . represents the current directory, it is a way to reference files and directories using a relative path. E.g. ./subdir1/subdir2/somefile

When you give the command ls, under the hood this is translated into ls .

The same is true for .., it is a way to reference the parent directory. E.g. ../../etc/cron.d.


These two entries are integral to the file systems on your machine, and are present in the list returned by the kernel's low-level directory listing functions.

As others have said, .. is a link to the parent directory, and . is a link to the current directory.

Some front-ends such as nautilus hide these two entries, because they aren't really as relevant in a graphical environment, but they are still there.

Why do they exist?

These are shortcuts for convenience. They're implemented across your entire file system to ensure that no matter which application you're using, they'll work - they don't depend on individual application support. They'll work anywhere that a directory path is allowed, including config files.

  • The .. shortcut allows you to refer to the parent of a directory with directory/.., its grandparent using directory/../.. and so on.

  • The . shortcut allows you to explicitly refer to the current directory, in cases where an application requires you to specify a directory (or directories) to search in and you want to search in the current directory.

    For example, . can be added to the PATH environment variable, allowing the current directory to be searched for matching executables by default. Or, if it doesn't exist in PATH, you can use ./myscript to run a script in the current directory, even though the PATH environment variable would not otherwise look in the current directory for an executable.

How they're implemented

In most traditional file systems the . and .. entries are implemented on-disk as directory entries which share an inode with the directories they point to - that is, they are like hard links to the current and parent directory, except that they cannot be deleted or modified.

With the help of the operating system kernel, the .. entry even works across mounts points, ensuring that the root of a mount point will have a .. entry implemented as a link to the parent directory where the mount resides. This happens regardless of filesystem types - it would happen even in virtual filesystems like /proc.

. and .. are reserved filenames - it is not possible to create an actual file or directory and give it . or .. as a name (although you can start a filename with these characters).

  • 4
    On traditional systems, the names . and .. are not virtual but completely real. I don't think things have changed enough that they'real virtual. Nov 11, 2015 at 13:17
  • 2
    You are correct, but if you go into a mount point and do a ls -ali you will see that there is a .. entry that correctly shows the inode of the parent directory even though it's mounted in a different filesystem - implying that even when these entries are stored on-disk, Linux is also generating them on the fly, so that .. works across filesystem boundaries. Nov 11, 2015 at 14:35
  • 4
    That's true — and that's when the cheating occurs. In all regular directories (those which are not the root of a file system), the dot and dot-dot directory entries are real and the inodes reported are real. When you're in the root of a mounted file system, the inode number of the dot-dot entry is faked by the system as a special case. On an unmounted file system, you'd find that the dot and dot-dot entries both have inode 2 (again, under old rules; there might be a modern file system type where the rule is different, but they'd have the same inode number). Nov 11, 2015 at 16:07
  • Thanks for teaching me something new - I've modified my answer Nov 17, 2015 at 0:04

The reason for existence and the use of . and ..

. and .. are entries which are normally present in every directory. Their meaning is not related to the working directory of a process (like shell) but to the directory the entry is in.

.. provides two-way linking of the directory tree structure while . is a convenient name for referring to the directory itself. The path directory/. is the same as directory. Theoretically an empty string could have been chosen to refer to the directory itself but in fact it is not like that: ls '' does not work and the meaning of an empty string would be ambiguous because at the beginning of the a path it refers to the root directory already: Would /file1 mean file1 in the root directory or file1 in the current working directory?

As thomasrutter showed it is important that as normal directory entries you can use . and .. in a path. For example ./-filename could be used to avoid interpreting of the dash character - as an introduction of command line options. The path directory1/../directory2 in effect is the same as ./directory2 which is the same as directory2.

Why are . and .. hidden?

File (and directory) names with . at the beginning are by convention hidden in Unix-like systems so by default most of tools will not show the . and .. directories. This is useful because we already know the . and .. are normally present in every directory.

The command ls -a shows all the directory entries. In Nautilus Ctrl+H turns displaying of the hidden entries on but with exception of . and .. because they are normally not very useful in a graphical file manager. For similar behaviour on the command line you can use ls -A.

Are . and .. real directory entries?

Yes, in the commonly used file system they are. (as Jonathan Leffler reminded) How can we check that?

# prepare the directory
cd /tmp ; mkdir testdir1

# test 1
ls -lid testdir1 testdir1/. testdir1/..
1179767 drwxrwxr-x  2 pabouk  pabouk  4096 Nov 12 11:52 testdir1
1179767 drwxrwxr-x  2 pabouk  pabouk  4096 Nov 12 11:52 testdir1/.
1179650 drwxrwxrwt 14 root    root    4096 Nov 12 15:17 testdir1/..

The inode number (1st column) referring to the data structure of the directory/file itself is the same for the same directory testdir1 and testdir1/.. The link count (3rd column) showing the number of the directory entries referring to the inode (directory/file) is 2 right after creating the directory because there is testdir1 in /tmp and . in /tmp/testdir1. The inode of /tmp/testdir1/.. (/tmp) has 14 links because it has 12 subdirectories containing .. + the 2 entries as every directory.

# test 2
touch testdir1/tesfile1   # to have a regular file too

debugfs /dev/sda2 -R 'ls -l /tmp/testdir1' | cat
debugfs 1.42.12 (29-Aug-2014)
 1179767   40775 (2)   1000   1000    4096 12-Nov-2015 11:52 .
 1179650   41777 (2)      0      0    4096 12-Nov-2015 15:46 ..
 1179771  100664 (1)   1000   1000       0 12-Nov-2015 11:52 tesfile1

The utility debugfs reads the ext2 (and newer) file system data directly from the disk sectors (bypassing the file system in the Linux kernel).

# test 3

debugfs /dev/sda2 -R 'dump /tmp/testdir1 '>(od -tax1)
debugfs 1.42.12 (29-Aug-2014)
0000000   w nul dc2 nul  ff nul soh stx   . nul nul nul stx nul dc2 nul
         77  00  12  00  0c  00  01  02  2e  00  00  00  02  00  12  00
0000020  ff nul stx stx   .   . nul nul   { nul dc2 nul   h  si  bs soh
         0c  00  02  02  2e  2e  00  00  7b  00  12  00  e8  0f  08  01
0000040   t   e   s   f   i   l   e   1   s   o   c   k   e   t nul nul
         74  65  73  66  69  6c  65  31  73  6f  63  6b  65  74  00  00
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
         00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00

If you do not believe the directory listing of debugfs you can examine the raw dump of the directory and check that the . and .. entries are really there.

  • 2
    Just a thing: those entries are not virtual, they actually exist on most unix filesystems. The comments on thomasrutter's answer on the kernel special-casing them for mount points is particularly interesting.
    – spectras
    Nov 11, 2015 at 16:42
  • 1
    @spectras: Thank you! I originally thought that but thomasrutter's answer was so convincing :) --- I have corrected my reply and I added demonstration that in ext4 . and .. are real directory entries stored in the file system. Nov 12, 2015 at 15:15

Short answer: . refers to your current directory, .. refers to directory above it, aka parent directory. /media is for mounting stuff like USB and partitions on your drive. Unless you explicitly attached an USB or mounted something there yourself , that directory will remain empty.

  • so the /media folder is only for mounting REMOVABLE media? The cd-rom drive that came with my computer (technically removable...) is mounted where then? Nov 14, 2015 at 17:08
  • 1
    @thinksinbinary well, that most-likely will go to /cdrom folder. I don't have access to a CD or DVD right now, but that would be my guess Nov 14, 2015 at 17:21

. is the current directory and .. is the parent directory. Take the following directory hierarchy as an example:

└── bar

foo/. and foo/bar/.. are foo.


Not the answer you're looking for? Browse other questions tagged or ask your own question.