inode structure of soft links vs hard links

Inode numbers are the same for hard links. How does this help me access the contents of the link after deleting the original file? Why is this different for soft links, where the inode numbers are different? I know how the inode structure works, but I still can't figure it out...

I hope this isn't a homework question! Here's a clue: one of the fields in the inode is a hard link counter. When a filename is deleted, the corresponding inode and data blocks are only marked for recycling if the link count has dropped to zero. So if there is a hard link to another filename...

A soft link is just a file which references another file by name, not by inode. Remove the target and you just get lost data and a broken link.

oh thanks!

When a file has multiple hard links, there is no notion of which is the "original" link. When you delete one of those links, that is all that happens. The other links remain valid. The file is not actually deleted (inode marked "deleted" and space released) until the link count in the inode goes to zero and no process currently has the file open.

A soft link is just a tiny file that contains instructions (a path) for reaching the target. It does not contribute to the link count in the target's inode, and indeed there is no requirement that the target actually exist. If the target file is deleted, the soft link (now broken) remains. To add to the confusion, note that a soft link is just a specially marked file and can itself have multiple hard links.

Originally Posted by rknichols and no process currently has the file open.

A very important point. Often I see the question "Why didn't the space get freed up when I deleted the file?" The reason is because the file NAME got deleted but not the file INODE because the file was still open by some process. 90% of the time it is a log file that was still being written to.

One of the beauties of lsof is it can show PIDs with large regular files open even when the actual file NAME is no longer there. Killing the PID (cleanly of course) closes the file and frees up the space. Until lsof became available one would have to reboot to kill all the PIDs and thereby free up mystery space.

This also explains how Linux can do software updates without requiring the user to reboot afterwards. In Windows, a library can't be deleted while in use; all that can be done is to flag it for deletion and store the replacement file somewhere. The switch is made when you shut down.

In Linux, the library can be deleted and the new one installed because all you're deleting is the name. The inode and data blocks remain available to any running program linked to that library. Only libraries not currently in use are completely deleted and replaced.