Seemingly Inconsistent Behavior for "ln" & "ln -s"

Question

As we all know, the ln command creates a link, with the default being a hard link and the -s option creating a symlink. The general syntax is ln [-s] OLD NEW, where OLD is the file you are linking to and NEW is the new file you are creating. Hard links can not be created for directories, as a hard link could be created between folders inside each other & I suppose computers do not yet have the resources to check for this without a SERIOUS slowdown.

When creating the link, the path of both files must be written out, and can be absolute or relative. You can mix relative & absolute filepaths, i.e. have a relative path for the new file/folder & an absolute path for the old one. When creating a hard link with a relative path, the paths of both files are relative to the current folder, while for a symbolic link the path of the linked-to file/folder is relative to its parent folder but the path of the old file/folder is relative to the current folder. Why this is is "relative" to my question.

For example, say we am in the HOME folder, /home/user, also known as ~, and create 2 folders, new and new2, with the file file in the folder new. If we try ln -s new/file new2/file, the result is a broken link from ~/new2/file to the currently nonexistent ~/new2/new/file. However, if we instead run ln -s ../new/file new2/file, we get the expected result, which is a link from ~/new2/file to ~/new/file.

So, my question:

Why is the file path for the OLD file/folder of a symlink relative to its parent, while the other 3 paths (hard link OLD, NEW files, symlink NEW file/folder) are relative to the current folder?

All this is on Fedora, but I'm sure it applies to most UNIX-based OS's.

EDIT E Carter Young seems to hit the nail on the head with regard to my 2nd question (as well as my 1st question, which was wrong anyway). It seems that for a symbolic link, the target doesn't have to exist yet, so the system has to make its path relative to the link rather than the current directory. However, why can't the shell parse out that path when you're running the command, rather than forcing the user to figure out what the path is & enter it him/herself? The shell seems to parse pretty well, so is this a case of legacy issues? Performance issues? What?

Answer 1

Read your man page: Question 1 = 1st Form, this is because in linux all items are considered files, even directories. As an example, use your text editor to "open" /etc/, ie: nano -w /etc/ nano will politely tell you /etc/ is a directory Since it's technically legal to create never ending symlinks. In the old days, before the bounds check was written, I could have an FHS system with 2 files named /etc, one being a file and one being a directory, and the system knew the difference

(See the haha note in the chromiumos developer guide:

There is a file system loop because inside ~/trunk you will find the chroot again. Don't think about this for too long. If you try to use du -s ${HOME}/chromiumos/chroot/home you might get a message about a corrupted file system. This is nothing to worry about, and just means that your computer doesn't understand this loop either. (If you can understand this loop, try something harder.

I Dare you, click on something harder :) In order to prevent the looping ln requires the full path.

Question 2 can be answered by reading the man page again Look at the last sentence:

DESCRIPTION

   In the 1st form, create a link to TARGET with the name LINK_NAME.  In
   the 2nd form, create a link to TARGET in the current directory.  In
   the 3rd and 4th forms, create links to each TARGET in DIRECTORY.
   Create hard links by default, symbolic links with --symbolic.  By
   default, each destination (name of new link) should not already
   exist.  When creating hard links, each TARGET must exist.  Symbolic
   links can hold arbitrary text; if later resolved, a relative link is
   interpreted in relation to its parent directory.

---

Re: Edit: "However, why can't the shell parse out that path when you're running the command, rather than forcing the user to figure out what the path is & enter it him/herself?"

---

Consider this example: Application A installs Library version 1.0.a. You build applications X,Y,Z that depend on Library A. Application A finds a bug, updates it and saves the library as 1.0.1.2.a. Since Applications X,Y,and Z still use library 1.0 if i replace 1.0 directly w/ 1.0.1.2, I'll get breakage, but if I symbolically link version 1.0.1.2 to version 1.0, nothing breaks,

ln -s /usr/lib64/libfoo-1.0.1.2.a /usr/lib64/libfoo-1.0.a

and applications X,Y, and Z get the new bugfix from the library applied to them too, because the shell follows the link from 1.0 to 1.0.1.2 but calls it 1.0. In cases like this you don't want the shell assuming the path as you increase the chance for system-wide breakage. BTW on 64-bit systems /usr/lib is linked to /usr/lib64, to remedy the example I just gave on a large scale, ie 32 bit applications expect libraries to be installed at /usr/lib, and on a 64 bit system there are no pure 32 bit libraries so /usr/lib is linked to /usr/lib64 like so:

ln -s /usr/lib64 /usr/lib

Answer 2

Question 1: Why does the whole path need to be written out for both files/folders for a soft link, while for a hard link we can leave out the filename for the target file?

You don't need to specify the path or the filename for the soft link too, unless the target is in the current directory. For example, if you have a file ~/Downloads/target_file, you can do:

ln `~/Downloads/target_file`

when you are in ~/, which will create a hard link to ~/Downloads/target_file in ~/ with the filename target_file and you can also do

ln -s `~/Downloads/target_file`

when you are in ~/, which will create a soft link to ~/Downloads/target_file in ~/ with the filename target_file.

Question 2: Why is the file path for the OLD file/folder of a soft link relative to its parent, while the other 3 paths (hard link OLD, NEW files, soft link NEW file/folder) are relative to the files/folders themselves?

All four paths can be relative(to the current folder) as well as absolute; the only criteria is the hard or the soft link should not be in the same folder if you are not specifying the name or path.

You should read the manual page of ln. Have tried all this on Ubuntu 14.04 but never the less have confirmed with the manual page so you don't need to worry about the OS; it isn't OS-specific.

Answer 3

When you create a hard link, the source path is used at the link creation time, so it must be a path relative to the current working directory (or an absolute path). When you create a symbolic link, the source path is treated as a string; it will be interpreted when the link is used, so it is relative to the directory where the link is.

Considering your example, where the current directory is /home/user.

• The command ln -s new/file new2/file creates a symbolic link whose text is new/file and puts this link at the location new2/file. When a program accesses that link, the target is /home/user/new2/new/file which doesn't exist.
• The command ln -s ../new/file new2/file creates a symbolic link whose text is ../new/file and puts this link at the location new2/file. When a program accesses that link, the target is /home/user/new2/../new/file which shortens to /home/user/new/file.
• The command ln new/file new2/file creates a directory entry at the location new2/file which points to the same file as /home/user/new/file (which must exist).

It's often less confusing to change to the target directory before creating symbolic links.

cd new2
ln -s ../new/file .