Hi,

"Can two files have the same inode number?"
on different partitions ? Is the inode no unique?
That also opens up another queries about " What exactly is a hard link ?

What is exactly an inode? If i delete the original file then would the hard link still open the original file? If yes ....why ?


pls clarify in details .....

2 files can have the same inode, but only if they are part of different partitions.
Inodes are only unique on a partition level, not on the whole system.
On each partition, there is a superblock. This superblock tells the system which inodes are used, which are free, etc (I'll spare you the technical details).
Each item on the disk -so files, but also directories, Fifo pipes and special device files- each have their own inode. All the inodes are stored on the disk, right beside the superblock (normally).

For instance in the case of regular files, inodes simply contain some informations like the last access/modification times, the size of the files, the file permissions, the disk blocks it occupies, etc.

For directories, inodes tell the system where the blocks that contain the contents of the directory are stored, as well as the last access/modified dates and permission on the directory.
You can see this if you look at the size of a directory via "ls -ld dir". It is usually an multiple of the size of a disk block (512kB or 1MB usually). The contents of directory blocks are nothing more than a list of name-inode pairs (ie a filename + it's inode number). When you do an "ls", those contents get printed, without the need for the system to actually locate all files in the directory. If you access a file or subdirectory, the system simply looks up the inode number from the directory contents and then retrieves the inode in question, so that you can have fast access to the file/subdirectory in question.

So, you can immediately see that the inode information describes directly what's on a partition to the system. It is the core of the filesystem on your partition.

Unless you are using special software like LVM to make the system believe that multiple physical disks or multiple partitions act as one partition, each partition needs to know it's own contents. Otherwise, you would never be able to share disks for instance via NFS mounting (each computer that shares the disk must know it's contents).

Continuing this line of thought, it is logical that inodes are unique on the (logical) partition level.

To answer your question on hard links. You first need to know what the difference is between a hard and a soft link (or symbolic link). Let's say you want to link A to B, regardless of what A and B really are (files, directories, device files, etc). Thus creating two ways of accessing the same item on your filesystem.

Using a soft link is easy. A and B both have their own inodes and both are part of different directories.
However, A actually contains the full path and name of B. When your system tries to access A, it will see the reference to B (via the full path), locate B by following the path and then access it. Since the full filesystem path is used, soft links work accross different partitions. If A is indeed a soft link to B on a different partition and B's partition is unmounted, then the link will continue to exist but will simply point to something unreachable. So you can't access A either. Same goes when B gets deleted. If A (the soft link) would be deleted, then B is still there, unaltered.

Hard links are a different story. As I explained, the contents of a directory are nothing more than pairs of inode numbers and names. The inodes are used to access the actual items in the directory. The names are just there for the ease-of-use, more or less. A hard link is nothing more than copying the inode number from one entry in some directory's contents into another entry. This second entry can be in a different directory's contents or even in the same directory (under a different name).
Since both directory entries have the same inode number, they point to the same item on the disk (ie the same physical file). Of course, inode numbers, as explained above, are partition-specific. So, duplicating an inode number on a different partition would not work as expected. That's why hard links cannot work across partitions.

Internally, the inodes of items such as files and directories also contain a link counter. This counter holds the number of (hard) links to the item. When you delete the item (using "rm" for instance), you internally "unlink" it (hence the term "unlink" instead of "delete" or "remove" that you see in some shells, like Perl). Unlinking simply decreases the link counter in the inode and deletes the entry in the directory's contents list. If the link counter drops to 0 (the last link is deleted), then the disk blocks occupied by the item get freed. When new items are created on the disk later on, they may use the freed blocks and overwrite them. In other words, when the last link is deleted, the item becomes unreachable (as if it was deleted from the disk). So, as long as the last link isn't deleted the contents of the item (file/directory) are still accessible and usable via the remaining hard links.

Symbolic links are created by "ln -s", hard links via simple "ln". See ln's man pages for details.

1 members found this post helpful.

I believe that a hard link will map two different names ("directory entries") to the same inode ("physical file")... by means of the inode number and not (as in a soft link) the name.

Hi,

Thanks all for your responses..I have indeed got a detailed explanation of my question.....Thanks Again

@sundialsvcs: Thanks for the summary.

I'm late!
that was very good detailed explanation,

where is inode number actually stored? that isn't on disk , is it?
i hear about it that the inode number is inode's address on disk, is it correct?
and another question, the inode table is stored on disk, is it?

so , please check this senario for any problem:
- when we want to read a file ,first of all we need to open it,and it is listed on system-wide open file table, and we(we are a running process and a sample proces, is it right?) recieve a handle called "file descriptor" then we use it with read(fd,...) syscall and what will be done internally is that it will seek for inode number from its inode-table and then refer to taht inode number (in fact, its adderess on disk) and read it to memory cache.

thanks in advance