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?

ctrl-alt-delor
  • 27,993
time_remnant
  • 21
  • 1
  • 1
    you created to names for the same file. – schily Apr 08 '20 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 Apr 08 '20 at 14:49
  • Does this other Q/A on Unix & Linux help you clearing your doubts? – fra-san Apr 08 '20 at 14:53
  • Also, https://unix.stackexchange.com/questions/88423/why-do-hard-links-seem-to-take-the-same-space-as-the-originals – Kusalananda Apr 08 '20 at 14:53
  • "How is it different from the original file?" -- is it? – ctrl-alt-delor Apr 08 '20 at 15:57
  • 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. – Paul_Pedant Apr 08 '20 at 17:46

1 Answers1

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
Oleksandr Suvorov
  • 123
  • 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). – ctrl-alt-delor Apr 08 '20 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. –  Apr 09 '20 at 07: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. – Oleksandr Suvorov Apr 09 '20 at 12:49