49

My understanding is that hard links include a copy of the original file, and that I could delete a hard-linked file in one location, and it would still exist in the other location.

If that's the case, why would I want to use hard links at all? Why not just have two separate files?

4 Answers 4

59

If you copy a file, it will duplicate the content. So if you modify the content of a single file, that has no effect on the other one.

If you make a hardlink, that will create a file pointing to the same content. So if you change the content of either of the files, the change will be seen on both.

4
  • 4
    For very large files, is creating a hard link always faster than copying the original file? Oct 15, 2015 at 4:40
  • 1
    @JorgeBucaran Creating a hard link is nothing else than creating a new name for an existing file. This is quick in comparison to copying the file's contents.
    – Kusalananda
    Jan 2, 2020 at 8:42
  • 1
    Can they have different file extensions? I work on WSL and want to share common aliases on both systems. So I want a hard link between common_functions.zsh and common_functions.ps1. Hard link is good because I can change either "brother" and both get changed.
    – Timo
    Nov 14, 2020 at 9:03
  • 1
    @Timo Of course they can have different file extensions. For OS, file exts are nothing but part of your file names.
    – C.K.
    Mar 31 at 2:42
25

A hard link is basicly a second filename for the same file. So if you hardlink a file, it will only be once on the filesystem, and therefore only take up space once. So you want to use this if you wish to save diskspace

5
  • 4
    Thanks for the prompt response. Then why would I want to use a hard link instead of a soft link?
    – Mike B
    Feb 16, 2013 at 18:11
  • 7
    A softlink is basicly a pointer to another file. So if you delete the original file, the softlink will still exist but will be broken. A hardlink are 2 names for the same file, so they can be individually deleted.
    – Peter
    Feb 16, 2013 at 18:13
  • 26
    Peter's explanation is good, but he's left out "link count". In the file's inode (on disk metadata) there's a link count. A hard link increments the link count, a soft link doesn't. The kernel is allowed to delete a file's contents if the link count drops to zero.
    – user732
    Feb 16, 2013 at 18:15
  • 4
    I think Alan's answer to this has an important point: changing a file changes all it's hardlinks, with a copy they would have different content. Feb 16, 2013 at 18:33
  • Do hard links really save space? Both by the Windows File Explorer (I'm using WSL) and by the directory file listing ls -l I can see that both files take up the same amount of space.
    – HERO
    Sep 14, 2021 at 6:30
13

On unix file systems every filename is actually a hard link to the location of the data on the disc, called an inode. If you create a new hard link to an existing file, it will take no extra space on the disk as it is just another pointer to the same data. If you edit the data by one or other link (or edit the inode directly) both files will be changed.

The system keeps a count of how many hard links each inode has. When the link count is 0, the file can no longer be reached, and the data is marked as safe to be overwritten. So given a file with 2 hard links, if you delete either link, the data will not be deleted. Only if you delete both will the data be gone.

You can see the inode numbers of files using the -i switch to the ls command.

A soft link, on the other hand, points to another file by its file name. If you move or delete the original file, the link will be broken.

2

With reference to the part of the question that asked, "why would I want to use hard links at all?":

Hard-linked files (or for that matter soft (symbolic)-linked ones offer a useful way of having a single executable file that can be made to masquerade for different purposes.

That is, the name by which the code is invoked can be examined in order to determine what options are available for execution. This allows the development and packaging of one large piece of code with all the shared functionality needed for slightly different purposes. From the user's perspective, the specification of "what" to run (by name) limits the choices and presentation to a more manageable subset of options.

A classic example is LVM. At one time HP-UX used hard-linked files for the various executables (e.g. vgdisplay, vgcreate, vgextend, etc. Today, like Linux, these commands are actually symbolic (soft) links to the lvm executable.

8
  • This has nothing to do with the question.
    – rjmunro
    Feb 16, 2013 at 23:06
  • 2
    @rjmunro I beg to differ. The OP asked, "why would I want to use hard links at all?"
    – JRFerguson
    Feb 17, 2013 at 7:14
  • I don't understand the last example. Once, there were hard links to lots of executables, now there are soft links to one executable. How are those soft links distinguishable? Feb 18, 2013 at 3:39
  • 1
    @EmanuelBerg Create a simple shell script that echos $0 (the name by which it is run). Now create one or more links to the script. Run the script with its original name and by invoking the link. The lesson should be obvious, then.
    – JRFerguson
    Feb 19, 2013 at 1:48
  • 1
    @EmanuelBerg TMTOWTDI
    – JRFerguson
    Feb 19, 2013 at 2:41

You must log in to answer this question.

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