The figure attached by jestin is good, but it might require further explanation.
In some non-Unix-like filesystems, the primary identifier of a file is its name. A file can have only one "true" name.
In Unix-style filesystems, this is not true.
The primary identifier of a file in Unix is *not* its name, but its inode number. An inode contains the important meta-data for the file, including:
- type (regular file/directory/symbolic link/block device/character device/named pipe/other...),
- owner and group,
- access permissions,
- change times,
- the pointer to the location of the file's data on the disk surface (if any).
If the inode is a device node, it contains the major & minor device numbers instead of the data pointer.
The inode does *not* contain the name of the file.
However, we humans don't like to refer to files by just numbers, so a "directory" is implemented to map the numbers to human-readable names and vice versa. A directory is just a special kind of file, which contains a simple list. Each entry in a directory file contains a filename and its associated inode number.
When a filesystem is structured like this, it allows creating multiple directory entries to one file. *This is what hard-linking is.*
Hard links are based on inode numbers, and inode numbers are guaranteed to be unique only within a single filesystem: this is why hard links cannot span multiple filesystems.
Usually a file has only one hard link pointing to it, and thus a file has only one name. But it is possible to create additional hard links using the "ln" command, or the "link()" system call. These additional links are every bit as true as the first one.
A valid way to move a file from one directory to another (or just rename it) within one filesystem is to first create a new hard link with new name and/or directory location, then remove the old link.
When a file has no hard links pointing to it and no process holding it open, the OS considers the file deleted: it will automatically free the disk space occupied by the file.
If a programmer wants to ensure that his program won't leave any temporary files lying around even if it's terminated abnormally, the programmer can have the program open a temporary file for access and immediately unlink() it. The program is free to read and write to the file, but no other program can access it (without special measures). When the program terminates for any reason, the OS will automatically remove the temporary file.
MK
MK
