If you do rm myFile where myFile is a hard link, what happens?

3 Answers 3


In Unix all normal files are Hardlinks. Hardlinks in a Unix (and most (all?)) filesystems are references to what's called an inode. The inode has a reference counter, when you have one "link" to the file (which is the normal modus operandi) the counter is 1. When you create a second, third, fourth, etc link, the counter is incremented (increased) each time by one. When you delete (rm) a link the counter is decremented (reduced) by one. If the link counter reaches 0 the filesystem removes the inode and marks the space as available for use.

In short, as long as you do not delete the last link the file will remain.

Edit: The file will remain even if the last link is removed. This is one of the ways to ensure security of data contained in a file is not accessible to any other process. Removing the data from the filesystem completely is done only if the data has 0 links to it as given in its metadata and is not being used by any process.

This IMHO is by far the easiest way to understand hard-links (and its difference from softlinks).

  • 13
    Moreover, the system call for deleting a file is unlink().
    – mouviciel
    Commented Oct 8, 2012 at 5:38
  • 1
    This doesn't cover the situation where the file is open when the last link is unlinked.
    – cjm
    Commented Oct 8, 2012 at 6:26
  • 6
    @OrangeDog, not exactly, because hardlinks can't cross filesystems, and /proc is a separate (virtual) filesystem.
    – cjm
    Commented Oct 8, 2012 at 9:18
  • 2
    /proc also mirrors the kernel's internal data structures (it's a way for the Linux kernel to expose certain data in a reasonably well-defined format without giving all and sundry direct access to kernel memory). So it's more accurate to say that the kernel keeps track of the fact that the file is open, and exposes that information through procfs.
    – user
    Commented Oct 8, 2012 at 11:11
  • 1
    And yes, calling unlink() to delete a file puzzled me to no end when I started playing with C programming on MS-DOS some time back in the first half of the 1990s. :)
    – user
    Commented Oct 8, 2012 at 11:13

Testing was easier than I thought: I created a text file, then hard linked to it. Deleting the hard link does not delete the file it is hardlinked to and the file that was linked to remains where it is.

  • 3
    this is true, but not a complete picture Commented Oct 8, 2012 at 5:26
  • 4
    The key is that creating the text file also adds a hard link. In *NIX filesystems, all files (inodes) must be hardlinked at least once into the directory structure.
    – OrangeDog
    Commented Oct 8, 2012 at 9:22

all files in your disk are actually pointers to the real data on your drive. enter image description here

when you make a hardlink for that file the hardlink-ed file will be pointing to the same data that the original file was pointing to.

enter image description here

as in this example, a.txt was pointing to the data(bytes) of the file that are in the drive, when the hardlink b.txt is created it will point to what a.txt was pointing to.

thus removing one of them will not affect the other one they are separated from each other.

BUT, when you remove both of them the system will see that the data that is on the disk has no file pointing to it, so the system will consider it as a free space and will overwrite it when it wants to.

  • 4
    I think it's important you clarify that FILE "A.txt" is identical to LINK "B.txt", particularly as you've called one a FILE and the other a LINK. The link is really the black arrow. Commented Jul 5, 2019 at 15:03
  • yes, I thought that it will not be clear that b.txt is a hard linked file...
    – Eboubaker
    Commented Jul 7, 2019 at 8:01
  • I have two questions here. 1) is "Actual Data On Disk" = Inode?. 2) Will the OS check the reference counter of a file every time someone execute rm command on that file?
    – Rain
    Commented May 13, 2021 at 20:46

You must log in to answer this question.

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