What's the deal with the "." and ".." in the directories? [duplicate]

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?

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

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
*
0010000

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.

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.