Skip to content
This repository
Browse code

Added new guide (WIP).

Guide name: Linux Filesystem Hierarchy Primer. Currently not
  • Loading branch information...
commit bd73c859d810afad42927db30026c828105abf67 1 parent 28ec63a
Wade Cline clinew authored

Showing 1 changed file with 180 additions and 0 deletions. Show diff stats Hide diff stats

  1. +180 0 content/blog/20130131_fshguide.mkd
180 content/blog/20130131_fshguide.mkd
Source Rendered
... ... @@ -0,0 +1,180 @@
  1 +title: Linux Filesystem Hierarchy Primer
  2 +category: blog
  3 +tags: guide
  4 +author: "Wade Cline <>"
  5 +date: 2013-01-31
  6 +---
  7 +
  8 +# Introduction
  9 +
  10 +This guide will provide a brief introduction to the Linux Filesystem Hierarchy (LFSH; ie, the filesystem *layout*) for those familiar with Windows. The first section will clarify any terminology used, the second sectoin will address frequently asked questions (FAQs) about the LSFH, and the third section will provide a brief rundown of the LSFH. The goal is to help new Linux users figure out where things are located.
  11 +
  12 +# Terminology
  13 +
  14 +## Folders vs. Directories
  15 +
  16 +Linux has directories; Windows has folders. In Linux, call them directories.
  17 +
  18 +# FAQs
  19 +
  20 +## "Where is `Program Files`?"
  21 +
  22 +Linux has no single location for most of its executable (think `\*.exe`) files. Instead, these files may be located in one of multiple, mostly pre-determined, locations. Most notably:
  23 +
  24 +* `/bin` contains non-administrator executable files necessary for system booting.
  25 +* `/sbin` contains administrator executable files necessary for system booting.
  26 +* `/usr/bin` contains non-administrator executable files *not* necessary for system booting.
  27 +* `/usr/sbin` contains administrator executable files *not* necessary for system booting.
  28 +
  29 +This probably seems a bit overly-complex at first; well, it'll soon get a bit more complex, but will then be simplified. While the directories above most often contain many important executable files, they are not necessarily the directories that will be searched when you try and execute a command via the command line. Specifically, the directories that will be searched consist of a colon-separated list of directories in the PATH environment variable. To see this environemnt variable, type:
  30 +
  31 + echo $PATH
  32 +
  33 +On my system, this gives:
  34 +
  35 + /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.5.4:/usr/games/bin
  36 +
  37 +Should I decide to run a command via the command line, the executable file for that command will be searched for in the following directories (with the top-most directory in the list being the first directory searched):
  38 +
  39 +- `/usr/local/bin`
  40 +- `/usr/bin`
  41 +- `/bin`
  42 +- `/opt/bin`
  43 +- `/usr/i686-pc-linux-gnu/gcc-bin/4.5.4`
  44 +- `/usr/games/bin`
  45 +
  46 +The command line processor will go through each of the directories until it finds an executable file whose filename matches the command specified, at which point it will stop searching and execute the matching file.
  47 +
  48 +Now, say I have multiple versions of the GNU Image Manipulation Program (GIMP) installed in various locations and am curious which version is executing when I run it via the command line; the above is an annoyingly long list of directories to have to go through by hand, so, instead of searching each directory by hand, I can simply run the `which` command to find out where the executable file is located. For example:
  49 +
  50 + which gimp
  51 +
  52 +returns:
  53 +
  54 + /usr/bin/gimp
  55 +
  56 +Thus one can determine where their `Program Files` are by running the `which` command, and by searching the directories in their `PATH` environment variable. Note that there may be other executable files on the system besides the ones which are immediately visible to the user.
  57 +
  58 +## "Where is my `Trash Bin`?"
  59 +
  60 +Maybe.
  61 +
  62 +The `Trash Bin` is not a directory belonging to the filesystem hierarchy itself; instead, the `Trash Bin` is most often implemented by the desktop environment and its window manager. You cannot rely on there being a `Trash Bin` on all installations of Linux; furthermore, there is often not an easy way to access the `Trash Bin` via the command line. What this means is that you should be very careful when deleting files via the command line in Linux, and also cautious when deleting them via your desktop environment.
  63 +
  64 +### "So then what's this `lost+found` directory?"
  65 +
  66 +Short answer: Don't worry about it; it's not a `Trash Bin`.
  67 +
  68 +Long answer: The `lost+found` directory is a special directory belonging to the ext\* series of filesystems (ext2, ext3, ext4) that usually appears at the base (specifically, the *mount point*) of the filesystem. Sometimes (hopefully rarely), bad things will happen to the filesystem, and chunks of data, known as *blocks*, may be lost and will not appear to belong to any file. In that case, those blocks of data are taken and placed into the `lost+found` directory during a filesystem stability (called *consistency*) check; the system administrator can then use the blocks of data in the `lost+found` directory to help recover any files with missing data.
  69 +
  70 +## "Where is my data stored?"
  71 +
  72 +The specifics may actually vary depending on how the system administrator decides to set up the filesystem, but your data is most often stored in:
  73 +
  74 +- /home/<username>
  75 +
  76 +So, if your username happens to be `vladimir`, your data would probably be located in:
  77 +
  78 +- /home/vladimir
  79 +
  80 +From there, everything else depends on your desktop environment and/or how you choose to organize your files.
  81 +
  82 +## "Where are my configuration files?"
  83 +
  84 +Most user-specific configuration files are stored in "hidden" text files known as *dot files*. Dot files are files whose names are prefixed with a dot (`.`), and are often located in the user's home directory; having their name prefixed with a dot keeps them hidden from normal `ls` commands; for example, running `ls` on my machine shows:
  85 +
  86 + Desktop blake cuda hobby media software work
  87 +
  88 +but running `ls -a` (the `-a` shows *all* files) shows:
  89 +
  90 + . .bash_history .cddb .dvdcss .gitconfig .kde4 .macromedia .thumbnails blake work
  91 + .. .bash_logout .config .fontconfig .gnupg .lesshst .mozilla .vim cuda
  92 + .TrueCrypt .bash_profile .crawl .gforth-history .gnuplot_history .libreoffice .recently-used .viminfo hobby
  93 + .Xauthority .bashrc .dbus .gimp-2.6 .gstreamer-0.10 .links .ssh .xsession-errors media
  94 + .adobe .cache .dmrc .git-completion.bash .gsview.ini .local .swp Desktop software
  95 +
  96 +Most of these hidden files are configuration files or are directories leading to configuration files for their respective programs; for example, `.gnupg` is a directory for configuration files belonging to the GNU Privacy Guard program.
  97 +
  98 +System-wide configuration files are mostly located in the `/etc` directory, and require administrative access.
  99 +
  100 +## "Where do my external drives (USB storage device aka 'USB stick', &c) appear?"
  101 +
  102 +Short answer: They are usually found under the `/media` directory once you have chosen to open (more specifically, *mount*) them via your desktop environment and window manager. In rarer cases, they may also be under the `/mnt` directory.
  103 +
  104 +Long answer: Anywhere and multiple places! I'll use a USB storage device as an example. The *block device* file (think: every single byte of data on the device, including filesystem metadata) for the USB stick will usually appear under the `/dev` directory (see the relevant entry below). The filesystem data itself may appear at a *mount point* that is created automatically by the system or is instead specified by the user; for example, one may choose to display the contents of their filesystem under `/home/vladimir/usb_stick` rather than `/media/usb_stick` by correctly invoking the `mount` command (the invocation of which is outside the scope of this document). In either case, the *block device* is still located under the `/dev` directory while the contents of the block device may be easily accessed at the *mount point*.
  105 +
  106 +# The Filesystem Hierarchy
  107 +
  108 +The following is a brief introduction to the actual layout of a Linux filesystem. First, the three levels of hierarchy, which I have decided to call *tiers*, of a Linux filesystem are explained, then some directories that are often common to multiple tiers are listed, and lastly certain specific directories are listed.
  109 +
  110 +Note that most distributions of Linux have additional directories that are not listed here, and, furthermore, the system administrator is often free to change the layout in order to suit their needs.
  111 +
  112 +## The Three Tiers.
  113 +
  114 +Each tier of a Linux filesystem is meant to serve a specific purpose. These purposes are mostly of relevance to system administrators, but are useful for the average user to know.
  115 +
  116 +### `/`
  117 +
  118 +The `/` directory, known as the *root directory*, is the basis of the entire Linux file hierarchy. Files located directly under this tier are files which are generally considered essential for system booting, repair, and restoration.
  119 +
  120 +### `/usr`
  121 +
  122 +The `/usr`, or *user directory*, holds read-only data that is useful for users but is not necessary for system maintenance. For example, highly-important programs such as Minecraft may be located under the `/usr` tier, but it is not necessary for basic system stability.
  123 +
  124 +### `/usr/local`
  125 +
  126 +The `/usr/local`, or *local directory*, is for locally-installed software. For example, say you are working on a video game using Simple DirectMedia Layer (SDL) but are having trouble with the library; you could download the library source code, hack the source code to add some debugging statements, then install a local copy of SDL into `/usr/local/lib` to test your video game without upsetting any other video games that depend on the version of SDL in `/usr/lib`.
  127 +
  128 +## Common directories.
  129 +
  130 +These directories are common to many tiers of the LFSH. Directories listed here are not necessarily be located in all tiers.
  131 +
  132 +### `bin`
  133 +
  134 +The `bin` directory contains architecture-dependent executable files; the "bin" stands for "binary", not "bin" as in "Trash Bin". Binary files are executable files that are written in a language that specific types of computers (specifically, computers with the same *architecture*) can understand. When run, these files are programs which can make the computer do... things; like video games.
  135 +
  136 +### `include`
  137 +
  138 +The `include` directory contains `header files` for use in the programming languages "C" and "C++". If you are not programming in either of these languages, then you will likely not have to worry about this directory. The directory is usually located in `/usr` and `/usr/local`, but not `/`.
  139 +
  140 +### `lib`
  141 +
  142 +The `lib` directory contains files which provide common functionality to multiple programs, usually in the form of architecture-dependent binary data. The "lib" stands for "library".
  143 +
  144 +### `sbin`
  145 +
  146 +The `sbin` directory contains architecture-dependent executable files that are meant for administrator use only.
  147 +
  148 +### `share`
  149 +
  150 +The `share` directory contains data that is "architecture-independent"; this means that the directory contains data that may be shared by multiple computers with different architrecutres that are running the same distribution of Linux. Note that data under this directory is likely *not* shareable between multiple distributions (such as Ubuntu, Fedora, and Gentoo).
  151 +
  152 +## Specific directories.
  153 +
  154 +### `/boot`
  155 +
  156 +### `/dev`
  157 +
  158 +### `/etc`
  159 +
  160 +### `/home`
  161 +
  162 +### `/media`
  163 +
  164 +### `/mnt`
  165 +
  166 +### `/opt`
  167 +
  168 +### `/proc`
  169 +
  170 +### `/root`
  171 +
  172 +### `/run`
  173 +
  174 +### `/sys`
  175 +
  176 +### `/tmp`
  177 +
  178 +### `/var`
  179 +
  180 +### `/usr/share`

0 comments on commit bd73c85

Please sign in to comment.
Something went wrong with that request. Please try again.