What is the typical real use case or application of symbolic/hard links in Linux?

Question

I understand the link concept in Linux, hard or soft.

Can someone please tell me the real use case?

Why do we need to keep multiple references to the same file? Isn't their management a problem?

If someone by mistake copies a reference instead of making a new reference of the original, I think it can be a mess with manageability aspect.

Answer 1

Any time that you want multiple names for the same thing, you need a link.

Shared libraries in Linux are named with their actual name, like in this example:

lrwxrwxrwx. 1 root root     16 Dec  2 15:24 /usr/lib64/libcurl.so -> libcurl.so.4.2.0
lrwxrwxrwx. 1 root root     16 Dec  2 15:04 /usr/lib64/libcurl.so.4 -> libcurl.so.4.2.0
-rwxr-xr-x. 1 root root 380864 Sep 19 07:04 /usr/lib64/libcurl.so.4.2.0

This is so that programs that want just any version of libcurl open libcurl.so. If they want version 4 they open libcurl.so.4. If they need the very specific version 4.2.0 they can open libcurl.so.4.2.0.

This is also used for programs like /usr/bin/java. Java can be provided by many different sources. It might be the IcedTea OpenJDK. It might be the Sun JRE. Or it might be the IBM version. Using a symlink lets the system point to a default version, while keeping each version in its own directory.

Answer 2

Links provide layer of redirection for a file name and its content. Regard this situation illustrated by Michael Jakl, in an article regarding use of rsync to mimic the behavior of Apple's Time Machine feature.

Answer 3

There are several uses of symbolic links in Linux, or *nix systems in general. For example, when you want to move the physical file location without breaking the existing or common "well-known" references, you may want to create a symbolic link at the old location. This is useful when you try to upgrade a commonly used tool with a private version, for whatever reason. Some utilities, such as busybox, uses a common binary to serve several needs. In certain Linux distributions, such as OpenWRT, the /bin/bash, /bin/ls, /bin/mv, etc. are all links to /bin/busybox. This binary is capable to behave differently based on the argv[0] used.

Answer 4

Real world examples of hard link usage can be found in /bin and other bin directories. Run the command ls -l /bin | grep -v ' 1 ' | sort. This will give you a list of commands with multiple links. Some commands will act differently depending on the name you call them with. (Busybox is an extreme case.) Hard links must be on the same device and don't require additional disk space.

Symbolic links are used heavily in /etc. It enables files located in other places in the hierarchy to be used without duplication. Symbolic links can cross device boundaries, but require additional disk space for the pointer.

Answer 5

To simplify backups

Use Case 1: Relocating documents to a separate local or NFS partition

Lets say you like to update your Operating System with each new release. A typical backup approach would be to copy your home folder to a separate partition so you can copy the contents back after the install.

What I typically do is symlink the folders I want to keep backed up to the separate partition. To restore the symlinks, I just run a quick bash script to restore the links after the OS install.

I would just call it backing up your data but there's really no additional 'backup' step. The nice part is if you accidentally pull a noob move like 'rm -rf' your filesystem, rm doesn't follow symlinks so you won't lose your files.

Note: I understand that you can change the location of where /home is mounted using /etc/fstab. The reason I don't use that technique is because I only want to selectively link parts of my user files and leave any accumulated junk behind.

Use Case 2: Using a cross-platform partition (the easy way)

The added benefit to using symlinks (soft links) is that they work across different filesystems.

Some of us don't have the luxury (due to business needs) of being able to use Linux as our only OS so we jump back and fourth a lot. To extend Case 1, what I personally do is use a NTFS partition for my user files and symlink out the various config and user files that I want to pull into Linux. That keeps all of my stuff in one place.

Note: If you didn't already know, you can also create symlinks in Windows using the MKLINK command.

Imagine this. You have a Dropbox account that you use in both Linux and Windows. To keep from having to download/sync two copies of the same files it's as easy to use everything across both OSes as symlinking to the Dropbox folder on the NTFS partition from your /home folder.

Note: To auto-mount a NTFS drive (in Debian based distros, not sure about others) you'll have to add an mount point in /etc/fstab with umask=000 for write privileges.

Use Case 3: To support default and custom folder structures simultaneously

Lets say you are a webdeveloper that is in charge of working on multiple websites.

You got your testing server setup properly in:

/opt/lampp

You could try to create one massive configuration that works across all sites but that will become cumbersome to maintain over time as new sites are added. The more sites you add the more out-of-sync the permission settings will be with the production server.

What happens when you want to drop in the production server config to test for security vulnerabilities or to verify that no server-side scripting errors are being displayed to the users. Do you just add another set of exceptions for that? How confident are you that your testing configuration is the same as the one the other developers on the team are using.

Apache specifically is extremely flexible when it comes to configurations but with flexibility comes complexity; and complexity introduces risk when you're writing code for the web.

Fortunately, there's a much simpler approach. Create a bash script for each website with --testing and --production arguments. Then just configure the arguments to drop the proper symlinks into the htdocs and config folders for the specific configuration. The site could be under version control, on a separate partition, or even on a remote share. It doesn't matter, as long as the symlinks point to the right place.