Hi,

My understanding of a soft link is that it has its own filename, inode, and data--where the data is the filename of the original file. Then if you use the command:

$ cat soft_link

it traverses the chain:

soft_link-->soft_link's inode-->data-->original's filename-->original's inode-->original's data

and then the original's data is displayed.

On mac os x, I created the original file and a hard link to the original file at different levels in the same directory (the same file system?), and then I created a soft link to the original file in a different directory(a different file system?):

myHomeDir/testing/dir1/original
myHomeDir/testing/hard_link
/unixTesting/dir1/soft_link

Then I did an ls -i on all those files, and they all displayed the same inode number. So, I formed a general rule in my mind: when you try to display the inode of a soft_link, you actually get the inode of the original file. That seems to be supported by the fact that if I rm(remove) the original and recreate it using touch original, the inode of the "new" original changes, and the inode displayed for the soft_link also changes(to the original's new inode number).

My understanding of hard links is that they don't have their own inode--they are linked directly to the original's inode, and that is why the inode for the hard link is initially the same as the original's inode. But when the recreated original gets a new inode, it breaks the hard link.

However, if I create original, soft_link, and hard_link in the same directory, then ls -i shows a different inode for the soft_link, and my general rule no longer holds. How should I interpret the fact that an ls -i on the soft link displays a different inode than the original's when the soft link is in the same directory as original? In addition, when I rm the original, and then recreate it using touch original, the original shows a new inode number, but the soft_link's inode remains the same, and the soft_link breaks. Why is that different from before?

I get an different inode number of a soft link than of a file it links to. And that's how it should be. Symlink is a kind of object that points to an file, but exists in its location. It has a different inode.

Hard links, on the other hand, are two different names to the same thing. That's why I get the same inode number for hardlinks.

When you remove the orginal file, you remove one pointer to it, in fact. The hardlink can be then considered as 'orginal'. So, when you re-create the file, you create a new file with different inode and so on. The hardlink does not point to it.

Hi,

Thanks for the response.

Did you create the soft link in a different file system? According to what I've read, inode numbers are unique only within a particular file system (although I'm not sure what constitutes a file system). Based on that, it seems entirely possible that a softlink in a different directory could have the same inode number as the original file. The directory my soft link is in has a different top level directory than the original file, and therefore I thought it might be in a different file system, and as a result it may have gotten the same inode number as the original file by the luck of the draw. I thought that maybe if I first created a dummy text file before creating the soft link, then created the soft link, that the the soft link would show a different inode number, but that isn't the case--it's always the same as the original's inode number(once again when the soft link is created in a directory with a different top level directory than the original).

That's what I thought as well, and that led me to conclude that the inode number that gets displayed for the soft link when I do an ls -i on the soft link is not actually the soft link's inode number.

I'm familiar with all of the following:
I just don't understand why my soft link shows the same inode number as the original and why it updates to the original's new inode number when I recreate the original. I would expect the soft link's inode number to be different than the original and not change when the original file is recreated.