2

I created a file in home directory.

touch demo
echo "This is demo" > demo

Now I created a hard link in /tmp

ln /home/leo/demo demoLink

Now when checking the inode using

ls -ltri demoLink

It shows the same inode number as the original file. I can digest that. But the file type of the Hard Link is Regular! How is it a regular file? How is it different from the original file? I read a file is an anonymous blob of data. So these two file are pointing to the same data? Is the file size of both hard link and Original file same?

6
  • 1
    you created to names for the same file.
    – schily
    Commented Apr 8, 2020 at 14:48
  • 5
    A hard link is just yet another name for an existing file. There is no filetype "hard link". The only difference between the original file and the new hard link is the name.
    – Kusalananda
    Commented Apr 8, 2020 at 14:49
  • Does this other Q/A on Unix & Linux help you clearing your doubts?
    – fra-san
    Commented Apr 8, 2020 at 14:53
  • Also, unix.stackexchange.com/questions/88423/…
    – Kusalananda
    Commented Apr 8, 2020 at 14:53
  • 1
    There is one place that the file type "h" shows up. If you use tar to archive the same inode twice because it has multiple hard links, then the second and subsequent tar headers show a type of "h", and the data is not copied out again. It is unclear to me how it deals with the case where a selective restore is requested using a name that is not the first, and the archive input is via a non-seekable file, such as a pipe from gunzip. Commented Apr 8, 2020 at 17:46

1 Answer 1

2

The hard link is not actually a "link". The first, second, third, Nth hard link to the same file inode are all equal to each other. There is no difference between an "original entry" and a "hard link".

Say, if one creates the file1 and then add the hard link file2 to the same file inode, there is no method to find out which link to the given inode is original.

I.e.

cryo@CryoNest:~ $ touch file1

cryo@CryoNest:~ $ ls -il file*
9505656 -rw-r--r-- 1 cryo cryo 0 кві  8 20:24 file1

cryo@CryoNest:~ $ ln file1 file2

cryo@CryoNest:~ $ ls -il file*
9505656 -rw-r--r-- 2 cryo cryo 0 кві  8 20:24 file1
9505656 -rw-r--r-- 2 cryo cryo 0 кві  8 20:24 file2

cryo@CryoNest:~ $ rm file1

cryo@CryoNest:~ $ ls -il file*
9505656 -rw-r--r-- 1 cryo cryo 0 кві  8 20:24 file2

cryo@CryoNest:~ $ ln file2 file1

cryo@CryoNest:~ $ ls -il file*
9505656 -rw-r--r-- 2 cryo cryo 0 кві  8 20:24 file1
9505656 -rw-r--r-- 2 cryo cryo 0 кві  8 20:24 file2

As you see, the inode number (9505656) and all attributes stored in the inode are equal for all hard links. Including size, date, mode, etc.

Pay attention to the 3rd field, this is a number of links to the inode. This field can be used to understand "mystical" situations when one "deletes" a file (actually, one of the hard links' directory entry) but space usage doesn't change :)

If one wants to find all hard links of the given file, the "find" tool has the option "-inum"

cryo@CryoNest:~ $ ln file1 tmp/file3

cryo@CryoNest:~ $ find . -maxdepth 2 -inum 9505656 -ls
  9505656  0 -rw-r--r--   2 cryo  cryo     0 кві  8 20:24 ./tmp/file3
  9505656  0 -rw-r--r--   2 cryo  cryo     0 кві  8 20:24 ./file1
3
  • 1
    In unix you dont' delete files. You remove directory entries. The OS will garbage collect it, if the hard-link count is zero, and the open process count is zero (not open by any process). Commented Apr 8, 2020 at 18:03
  • the mystical situation comes exactly from NOT distinguishing between first (last) and Nth link. That must be the reason why you left out "first", before it got edited. I downvoted because you mix up link and hard link.
    – user373503
    Commented Apr 9, 2020 at 7:23
  • @ctrl-alt-delor, I tried to answer the topic starter as simply as could. If I have a free minute, I'll add the note about differences in removing a directory entry and deleting an inode from the FS. Commented Apr 9, 2020 at 12:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .