Hard link and Symbolic links in Unix

Question

Hi All,

I just wanted to clarify if a hard/symbolic link is actually a file that is created ??

I ran the command:

ln source hardlink
ln -s source softlink

-- The ls command shows this 2 links as a file.

So my query is, does ln / ln -s actually create a file?

Regards, darkie15

Answer 1

Neither one creates a file.

A file on disk is identified by an "inode." Directories map filenames to inodes. A hard link means "create a new filename in this directory that points to the same inode as the file I name."

A symbolic link means "create a new filename in this directory that points to whatever inode this other files points to."

As mangoman points out in a comment, a symbolic link does create a file with the name of the link target, but you shouldn't pay attention to it. It's a special file that is None Of Your Business.

Answer 2

Yes, and no :-)

In UNIX, the contents of a file are distinct from the directory entries for that file. You can have multiple directory entries point to the same contents (look up inode for a description of how this works) and, here's the tricky bit:

All those directory entries are equal. Even though one may have been created first, there's nothing special about it. If you remove it, the contents don't disappear, just the directory entry. The contents will disappear once the inode has zero directory entries pointing to it (and all processes close the file - I've been bitten before by trying to clear up disk space deleting log files only to find that, because a process still has the file open, the file contents aren't recovered even though no directory entries point to them).

That's for hard links.

Soft links are a bit trickier. They do create a "file" of sorts (a separate inode), containing the path to the target file. And those links are not equal. Deleting the original will leave you with a soft link pointing nowhere.

Because inodes are unique on a given filesystem, hard links cannot refer to data on a different filesystem.

Soft links do not have that limitation since they store the path to the target file, not its inode.

The following transcript may help:

$ echo hello >f1
$ ln f1 f2
$ ln -s f1 f3
$ ls -ial f*
    7385 -rw-r--r-- 2 pax None 6 May 11 14:09 f1
    7385 -rw-r--r-- 2 pax None 6 May 11 14:09 f2
    4672 lrwxrwxrwx 1 pax None 6 May 11 14:09 f3 -> f1
$ cat f1
    hello
$ cat f2
    hello
$ cat f3
    hello
$ rm f1
$ ls -ial f*
    7385 -rw-r--r-- 2 pax None 6 May 11 14:09 f2
    4672 lrwxrwxrwx 1 pax None 6 May 11 14:09 f3 -> f1
$ cat f1
    cat: f1: No such file or directory
$ cat f2
    hello
$ cat f3
    cat: f3: No such file or directory

I've used only the last four digits of the inode number to keep the entry short (and not hit you with inode numbers like 43910096366994672) but you can see that f1 and f2 have the exact same inode whereas f3 is different. You can also see that the contents of the file created originally as f1 survive its deletion because f2 is still referencing it.

However, because f3 is referencing the f1 name rather than its inode, you get an error trying to use it.

---

Aside: You've gotta love it when UNIX toys with you like this:

$ ls f*
    f2  f3
$ cat f3 # What the ...?
    cat: f3: No such file or directory

Almost as much fun as creating a file called spacebackspacex and then watching somebody try to delete it :-)