In my own LFS-based OS, I had created many softlinks. Soft-link can be deleted without harming the target.

But is there any way that If I remove the a file or directory then, I will be notified about it's soft link ? So that there will be no dangling soft-link pointer.

Occasionally, finding dangling soft-link and then deleting is the way. But that will be static solution. I'm looking for dynamic way


Unfortunately not. Soft link (aka symbolic link or symlink) destinations do not keep track of the fact they are linked to. Its not really possible, either: symlinks can cross filesystems, so the link could be on a different filesystem, which isn't even currently mounted.

You could of course add a cron job to search for broken links nightly, and notify you. To find broken links, see How can I find broken symlinks (another question on this site).


It is not possible to do that with soft-links, because in the case of soft links targets are not aware of the existence of the links to them.

However, if your destination and source files are on the same partition, you could use hard links instead. With hard links there is a counter in the inode they point to, which keeps track of how many hard links (files) are linking to the inode.

You can see that counter by using the stat command (or system call). The output looks like this, look at the links field, it shows how many links/files are pointing to this file's inode:

~ $ touch testfile1
~ $ ln testfile1 testfile2
~ $ stat testfile1
  File: ‘testfile1’
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d      Inode: 7062809     Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/     mst)   Gid: (  100/   users)
Access: 2014-01-04 10:19:27.899679948 +0300
Modify: 2014-01-04 10:19:27.899679948 +0300
Change: 2014-01-04 10:19:33.149679891 +0300
 Birth: -

So before deleting a file you could check the stat's of it, if the Links field is above 1 there has to be another hard link to it. Unfortunately, to find the second hard link based on an inode will be an expensive search operation, so I hope you have some kind of naming scheme to find them faster.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.