Open a terminal, type "man 1 ln". When the text shows up, you are usually in a less(1) paged window - type "/-s" to search for the option, "N" key to search forward, shift+"N" to search backwards.

If you see a reference like $name($number), you can get to the manpage with "man $number $name".

"man man" for the general man invocation, and "man less" on how to interact with the less pager.

I would recommend relative symlinks (ln -rs). Makes it easier to rename the homedir for example.

On a copy-on-write filesystem, linking may not have much utility vs. copying.

Same, after learning the hard (pun intended?) way about hark links, I just default to soft links.

A symlink can point to anything, including a file that doesn't exist:

  [~] 0 $ mkdir tmp/demo
  [~] 0 $ cd tmp/demo
  [demo] 0 $ ln -s foo bar
  [demo] 0 $ ls -l
  total 1
  lrwxrwxrwx 1 user users 3 Nov 15 12:14 bar -> foo
  [demo] 0 $ cat bar
  cat: bar: No such file or directory
  [demo] 1 $ echo foo > foo
  [demo] 0 $ ls -l
  total 2
  lrwxrwxrwx 1 user users 3 Nov 15 12:14 bar -> foo
  -rw-r--r-- 1 user users 4 Nov 15 12:14 foo
  [demo] 0 $ cat bar
  foo
  [demo] 0 $ rm foo
  [demo] 0 $ cat bar
  cat: bar: No such file or directory
  [demo] 1 $ ls -l
  total 1
  lrwxrwxrwx 1 user users 3 Nov 15 12:14 bar -> foo
  [demo] 0 $

1. This depends on the filesystem. For ext2/3/4 (and many others) there is a reference count maintained in the first inode of the file. You can usually see this count in the output of "ls -l", between the perms and ownership columns. If someone goes wrong and the count isn't decremented properly (due to a system crash while the inode is being updated) or is otherwise corrupt, the space allocated to the object may never be released when it is deleted because the count will never reach zero. This is one of the checks/fixes fsck.ext* does when run. If the count is somehow too low the content could be deallocated too early, resulting in corruption (the remaining link(s) ending up pointing to the wrong data when the inode is eventually refused). Again fsck can detect this, but only if it is not too late and things are already mislinked or some of the space relocated.

2. A dangling soft link points to nothing valid. If you try to access it in a way that would normally give you the object it points to there will be a not found error. If a new object of the destination name appears the link will start to work again but give the new content. If relative links are moved around out of step with what they point to this can cause significant confusion. This is not filesystem level corruption that fsck can/will check for.

For 1, the inode probably has a reference count that's incremented when creating a hard link and decremented when deleting one. If the count is 0, the inode can be deleted.

AFAIK between two hard links, both are equal. None is more "the real" file than the other.

You can point at softlink at any path, even one that doesn’t exist. Create a regular file, now softlink to it, delete the regular file - now your softlink is dead.

Sorry about that! I hand-wrote the whole post on my tablet. More motivation for me to write more legibly next time!