In this video we are going to talk about three topics: the Linux file system layout, finding files, and file links. While these might not seem to have that much in common, understanding each of these topics is critical to knowing how to manage the files, both system and user files on a Linux deployment.

Understanding the Linux file system hierarchy standard

We'll start with the Linux file system hierarchy standard, FHS. There might be relatively minor variations between Linux distributions, but the location where you'll find a file on, say Ubuntu, is more often than not the place you'll find it on Fedora as well. Being confident that files will generally exist in the same place on every system isn't just convenient for users and admins, but it also makes it much easier to develop software and scripts. So it's very important for you to understand the FHS and get to know your way around Linux. Although we did touch on the structure a bit on the introductory course, and have encountered many examples through our previous videos, we'll now go through the key directories one at a time, working alphabetically.

/bin contains basic system binaries, including many of the command line tools we've come to love, like CP, RM, and Bash. /boot includes the files needed to get the system up and running, like kernels and INITRD. /dev contains links representing hardware devices, like disk partitions. /etc contains most of the system configuration files, including fstab and group. Beneath /etc lie other important directories, including opt, O-P-T, for package config files, and the skel directory, which contains a template of files and directories that are installed to a new user's home directory when he first logs onto his account. /home is where users' personal files and directories are placed. /lib is where shared directories used by root and during boot are stored. /media and/or /mnt, M-N-T, are directories for mounting peripheral devices. /opt is a location where software packages can store static files.

/proc is a pseudo file system, where running processes are represented. /root is the root user's home directory. /run is where programs can store temporary data. The contents of run will not survive a boot. /sbin contains key system binaries. /sbin contains key system binaries like fsck, shutdown, and route. /srv contains site specific data that is served by this system, meaning it's a good place to keep the files served by a local web server. Many systems will keep web files in /var/www instead. Both work. /sys is not actually part of the official file system hierarchy standard, but has become very common to keep system hardware information and subdirectories beneath /sys. /temp is similar to /run, in that files that don't need to survive a boot or can be overwritten if necessary, can be saved. /usr and the subdirectories that live beneath it, contain read only user data. /usr/bin contains non-essential system-wide binaries. /usr/lib contains libraries needed by binaries in user.

/usr/sbin contains non-essential system binaries. /usr/Share contains a great deal of shared data for installed programs. And /usr/src contains source code. Finally, /var is home to files whose content is expected to change regularly.

Subdirectories beneath /var include /var/cache for application cache data, /var/lib for state information, /var/log for system logs, and /var/mail for user's mailboxes. /lib is now often a symbolic link to /usr/lib, and /bin is similarly symbolically linked to /usr/bin, making these directory pairs effectively interchangeable.

Using find and locate to search a Linux filesystem

Even if you're pretty familiar with the basic file system hierarchy, you may still sometimes have trouble finding a specific file or figuring out exactly what it does. Linux has some particular good tools that can provide some quick help. Find can be used to accurately search through directories for files.

find /etc/ -name *.conf will search the etc directory for files with names that end in .conf. We use sudo because normally users don't have read access on some of these subdirectories. Let's ask find to find us every file called fstab, starting this time with the root directory. It'll find our fstabs, but it will take a long time getting there. That's because there are many tens of thousands of files in my system spread among hundreds of directories. Just reading through them all takes time. However, there is a better solution. locate fstab will return all the fstab files in just a second or two.

How does locate do this magic? Simple. Like all magicians, it cheats. Whenever I run updatedb, it updates a database of all system files, using the parameters defined in etc/updatedb.conf. When I then run locate, rather than searching from directory to directory, it simply reads a database, which is a very great deal quicker.

whereis will display the location of a binary program, its source code, and its manual file. Running whereis without any argument is equivalent of running it with -bms. B stands for binary location, M for manual file, and S for source code. I don't happen to have the source code for CP on my system. However, if I were to run it with only one or two arguments, it would return only the specified details. You will note that which will similarly display the location of a binary program, while type will show you how a particular program will be executed in the current environment. In this case, we're told that ls will execute with automatic color display.

Let's review. Find and locate will both search your file system for file names. Find is perhaps the more versatile and customizable of the two, but locate can, under the right circumstances, be much faster. You update the database that locate reads using updatedb. Whereis will identify the location of the binary, source code, and manual files of a program. Which will find the binary, and type will display the program execution parameters.

Working with hard and symbolic links (symlinks) and inodes

We mentioned in a previous video that each file on a Linux system is associated with an Inode. The inode is a data structure that stores the file's attributes and disk block location. Without an inode's data, you wouldn't be able to find, much less use a file. It is possible however, for two files to actually share a single inode.

But before we go there, we'll take a step backwards. You can obviously copy files from one location to another. What this does is create two identical files, each with its own inode pointing to its particular location. If you should edit either one of these files, the other one will, of course, not be affected. From here on in, they're not related in any way. However, if you don't really want two separate files in two locations, but you just want to be able to access a single file more conveniently, then you can create a link between two locations. From that point, executing or editing the file in one location will cause the linked version to undergo the same changes. They are in effect, synced to each other. There are two types of linked files: symbolic links, which while remaining in sync with each other, maintains separate inodes, and hard links, which actually share a single inode. We'll talk more about these later.

Symbolic links are usually referred to as symlinks. But why should you want to do this? I actually do it quite a lot when I find myself deeply nested in a particular directory hierarchy, and in need of a particular file. Knowing in advance that I'll often need this file under similar circumstances, I'll create a linked copy so I can easily access and update the link, but have it available in its up to date version in its original location.

Linux itself creates many linked files to make scripts more efficient, or perhaps, to keep binaries within the path, making them simpler to run. Let's illustrate this. We'll run ls against the vi binary in /usr/bin. We see that the first character of the output is an L, which stands for link. And the local file name is followed by an arrow pointing to another copy of vi in the /etc/alternatives directory. Let's do the same thing with the /etc/alternatives version. We can see its arrow pointing back to the /usr/bin directory, this time to the full binary name, vin.basic. These two files are linked together as symlinks. If you would delete the parent file, the linked version would be removed.

Let's try creating our own symlink. We'll create a link to the cp binary in my user's home directory, something that won't actually accomplish anything, of course, since cp is in our path in any case. We use ln -s, the cp binary, and then the location where we'd like the symlink to be created. When creating links, you always have to use full paths. We can see our new symlink, identified by the l at the beginning, and the arrow pointing to its parent at the end.

Creating a hard link works pretty much exact same way as a symlink, but without adding any argument to the command. This will create a link between the stuff1 file in my home directory, and a new file in the files directory. In this case, there is no l, or a link to the parent file, because there really is no parent file. With hard links, because the two files share a single inode, there's no way to tell the difference between them. So they both look like unique files.

Let's review this. A symbolic link can be identified through ls -l by the l at the beginning, and the link information at the end. A hard link, because it shares a single inode with its parent, will appear like any other file. You create a symbolic link using ln -s, followed by the full location of the parent file, and then the directory where you'd like the link to go. You create a hard link with ln and no arguments. And follow the same format as you would for a symlink.