Creating links in UNIX filesystems

This should be pretty straightforward, yet sometimes I find myself reading for the millionth time the manpage. Perharps this is more memorable.

Symbolic links (AKA symlinks) and hard links are both created with the same command (ln) and it follows the same syntax as the cp or mv commands. In most cases that would be:

<command> <“-s”-option-if-symlink> <original-or-source> <where-to-place-the-thing-in>
e.g;

• ln -s /etc/someapp/somefile.conf /home/serveradmin/tempbackups

TARGET vs DESTINATION

The part I think is confusing is that when working with files e.g. moving and copying, which is the thing regular users associate the most with filesystems, TARGET means “the place to send it (the file to copy or move)” while SOURCE would be the original. Whereas the with ls command, TARGET is used like it’s used in web pages that is TARGET as in the target of a hyperlink (or nowadays just “link”).

That’s kind of the thing about it; files listed by a filesystem are indeed like links on a web page (I’d say specifically a wiki) they’re associations to the data itself. These associations are called hard links, and like web pages [of a wiki], as long as one exists to the data, you’ll be able to make it to the data, but when when you delete the last hard link — though your data might still be there, and likely it is — without really knowing your shit it would be impossible for you to get back to the data if the link is gone.

Putting it in that context it makes sense again, but when you’re in the command line working with files, where that’s universally known as the SOURCE (remember, most filesystem operations involve moving or copying), maybe a little clarification on the manpage wouldn’t hurt, but y’know, Linux devs are very smart but they lack an aesthetic-, and common sense.

If you happen to be a Linux dev, or any dev really, please don’t take offense, instead put lots of emphasis in common of common sense. Y’know… like us lowly commoners who aren’t up to your level. We aren’t. Help us up. Spending just a little extra time putting things in a way we might have less issue understanding can mean you’ll have more people there with you. You’re brilliant, you understand patterns, it shouldn’t take you too much. I don’t make apologies about aesthetics though. Why so much obsession for Ubuntu orange, Material Design. Ubuntu is hideous there a reason orange is used on inmate (not judging) jumpsuits, Material is uninspired and uninspiring at best. Aero, Metro, Aqua? Bitch, please¹.

Having said that, you should be able to figure it out on your own, but since this document is also for future me who I know won’t be patient enough to read about this [yet] again, I’ll add some easy to spot examples for that lazy motherfu****.

Single-argument form

If you are in the directory where you want to create the symlink, i.e. inside the destination container, you may drop the second argument e.g;

serveradmin@www:~/tempbackups$ ln -s /etc/someapp/somefile.conf
serveradmin@www:~/tempbackups$ ln /etc/someapp/somefile.conf

These would create the file ~/tempbackups/somefile.conf².

Send-to-a-container forms

• ln /etc/someapp/somefile.conf /etc/someapp/somefile.ini /home/serveradmin/tempbackups
  • i.e. ln FILE1 FILE2 DESTINATION
• ln -t /home/serveradmin/tempbackups /etc/someapp/somefile.conf /etc/someapp/somefile.ini
  • i.e. ln -t DESTINATION FILE1 FILE2

The first of these is the most commonly used syntax (mentioned at the beginning). Both of these create one or more pseudo-copies³ on a destination directory (/home/serveradmin/tempbackups), which is the main difference from the following form,

Specifying a new name

• ln -T /etc/someapp/somefile.conf /home/serveradmin/tempbackups/app-parameters-change-here
  • ln -T NEW-NAME-AND-OR-PATH FILE1

Rules and background

• [Hard] Links are also known as inodes (index nodes,) associates a name to a file on a filesystem. For each file there must be at least one hard link. i.e. Most files in a filesystem are hard links.
• Symbolic or soft links, point to the path where a file resides. Unlike hard links, they do not link to the data itself.
• For hard links, the source (or “target”) must exist.
• For both, the destination should not exist. You should in theory be able to overcome this with the -i or -f options but personally I have never been able to make it work.
• You can only hard link files, not directories. It may be doable to hard link directories but it will not be trivial.
• Rather uselessly⁴, you can change the permissions of a symlink itself with chmod in macOS but not in others. I suppose there might be exceptions.
• File management commands such as mv and rm work on the symlink itself, which if viewed in some file managers — such as in macOS’s Finder where it appears as a file with a little “shortcut” arrow — they may be aliased (symlinked), deleted, dragged+dropped, and renamed as any other file keeping its associated file or directory unaffected.
  • However, be careful as some commands, e.g, cp, rsync, can recurse down through symlinks if using the right [and very common] options.

1. Windows’ Aero, Metro and macOS’ Aqua UI suck if you have the freedom to place elements wherever and however you please. None can compete against the polish of GNOME3 despite its lackluster iconography and bad use of screen real estate nor against the insane potential Plasma Workspaces 6 (also despite iconography). Old Deepin killed it, Cosmic is a long way but onto something and moving fast. Take inspiration on those. ↩︎
2. Where ~, means the same as $HOME or %{HOME}. That is the variable referring to the current user’s home folder. ↩︎
3. They’re not actual copies of the data nor of the original link, they are new independent pointers to the existing data [that were based on the existing pointer] ↩︎
4. Because Apple has rendered California-themed macOS worthless as a server, where this would be the most useful. ↩︎