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.
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 $
What you can't see because this is flat text is that in my terminal the first and last "bar -> foo" are red because ls is warning me that that link points to a file that doesn't exist.
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.
I know its required to store this count such that the filesystem would know when it can actually delete the inode, but isn't this half-way to making the inode aware of the paths pointing to it?
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.
You can also type "man 7 inode" and "man 7 symlink" into your terminal and have the information from the primary source.
Wow, this was super helpful!
I’ve always have that underlying question of “why is it always ln -s” and ln -s just became a muscle memory without any reason.
Good post!
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.
Nice! Two questions for me to follow up later:
- How the OS knows it can clean up an inode after a hard link is deleted? The post mentioned inodes don't see hard links
- What does it mean to have a dead/dangling soft link?
A symlink can point to anything, including a file that doesn't exist:
What you can't see because this is flat text is that in my terminal the first and last "bar -> foo" are red because ls is warning me that that link points to a file that doesn't exist.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.
I know its required to store this count such that the filesystem would know when it can actually delete the inode, but isn't this half-way to making the inode aware of the paths pointing to it?
This is correct, for ext2 at least. See [0], bytes 26 and 27
[0] https://wiki.osdev.org/Ext2#Inode_Data_Structure
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.
In UNIX actually.
The pics are VERY difficult to read
Sorry about that! I hand-wrote the whole post on my tablet. I will try to write more legibly next time!