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.
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.
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.
This got upvoted again so I decided to add another common 2 more use cases.
Use Case 4: Making applications easily accessible via the command line
Lets say you install a new application such as Sublime Text to "/opt/Sublime Text" to give user-level access without requiring root privileges.
To make it easily accessible via the command line one common approach is to modify the $PATH variable to include the Sublime application directory. This approach may be less than ideal because $PATH has a limited length, tends to get polluted with a lot of links to shared library paths, and is more difficult to remove later.
Since /usr/bin (ie one of the main application directories) is already included in $PATH, why not piggyback on that?
The simplest approach is to create a symlink /usr/bin/ pointing to the Sublime Text executable.
sudo ln -s "/opt/Sublime Text/sublime" /usr/bin/sublime
Now launching the Sublime text editor from the command line is as simple as typing sublime in the terminal. Sudo is only required when you create/delete the symlink because /usr/bin have user-level execute privileges by default.
Use Case 5: Seamless backup and selective sync to the cloud
Among the IT crowd one of the most commonly parroted pieces of advice is 'back up your files'. But backups are so '2000 and late'.
While there are a lot of available file synchronization services available they're not very flexible when it comes to organizing files. Usually, they require their own folder placed in the user directory and not all support selective sync. That's OK because symlinks solve both problems.
In the case of folder location, who cares. Unless you want to sync your whole home directories contents (ie I prefer to be more selective about backups) that's a good place for it.
As to 'what' you sync. That depends on your preferences. Personally, I prefer to keep things like game saves, software development projects, documents, portable software, and configurations synced to the cloud while syncing photos to a different service that is more tailor made to imagery.
I recently had my main desktop computer (ie an iMac) experience an internal hard drive failure after 6 years of use with 0 data loss. Sure, I had to reinstall the OS, applications, and re-link everything but it felt good to have a fresh start and I was able to script much of the process to make it easier to do in the future.
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.
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.
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.
