Hacker News Reader

Comment by athoscouto | Hacker News Reader

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?

View on HN

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.

This is correct, for ext2 at least. See [0], bytes 26 and 27

[0] https://wiki.osdev.org/Ext2#Inode_Data_Structure

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?

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.

Reply on news.ycombinator.com