link file1.txt file2.txt

file1.txt contains ham and file2.txt contains cheese.

I added 123 in file1.txt. Now file1.txt has ham123. If my understanding is correct, any changes made in either file would affect the other, but file2.txt is not changed. Why not?

Here's my edition with complete and exact output of my commands:

$ ls -li
total 16
1363827 -rw-r--r--@ 1 kim  staff  13 Jan 20 20:09 file1.txt
1363844 -rw-r--r--@ 1 kim  staff  22 Jan 20 20:09 file2.txt
$ cat file1.txt
$ cat file2.txt
$ link file1.txt file2.txt
link: file2.txt: File exists
$ ls -li
total 16
1363827 -rw-r--r--@ 1 kim  staff  13 Jan 20 20:09 file1.txt
1363860 -rw-r--r--@ 1 kim  staff  10 Jan 20 20:11 file2.txt
$ cat file1.txt
$ cat file2.txt

As you can see, I deleted everything inside file1.txt. However, file2.txt hasn't been modified. Both files are in the same directory. I used my text editor to create them.

  • I am referring to a hard link, not a soft link. – Mint.K Jan 18 '17 at 5:15
  • 2
    Did file1.txt and file2.txt both exist when you ran link file1.txt file2.txt? Are they in the current directory? If they both existed, link should have failed with link: cannot create link 'file2.txt' to 'file1.txt': File exists. Please edit with complete and exact output of cat file1.txt, cat file2.txt, and ls -li file1.txt file2.txt. The -i flag makes ls display a column for inode number, revealing whether or not file2.txt was really successfully created as a hard link to file1.txt. A hard link is just another name for the file and so always has the same contents. – Eliah Kagan Jan 18 '17 at 19:45
  • 1
    @Mint.K: If the command link file1.txt file2.txt was successful then it is impossible for file1.txt and file2.txt to have different contents, because they are just two different names for the same file. – AlexP Jan 19 '17 at 4:17
  • @Eliah Kagan I've just edited my post. – Mint.K Jan 21 '17 at 4:32

TL;DR: Making a hard link does not create a relationship between different files that causes new changes in one to be reflected in the other. Instead, it creates another name for the same file. Your link command failed because you told it to create a link called file2.txt, but file2.txt already existed.

Like people and things in world, a file can have more than one name.

Often it is useful to have some way to refer to something. For some things, it is useful to have more than one way. This is not limited to computing.

For example, "acetaminophen" and "paracetamol" refer to the same medication. It is correct to say acetaminophen is paracetamol and equally correct to say paracetamol is acetaminophen. Neither name refers to the other -- instead, they refer to a particular chemical substance, which is not the same thing as any of its names.

Just as a word or phrase may identify a person or thing in natural language, a link -- also called a hard link -- identifies a file, and some files have multiple links. They aren't links to each other, but to the file. (To be precise, what they identify is the file's inode. See below.)

When there are multiple links to a file, it's not that the file has one true name and others are false or lesser names. Instead, all links provide names for the file, and none depends on the others. If someone asks you for the name of a file then, no matter which of its hard links you specify, you are equally correct.

When you ran link, it did not succeed, and no link was created.

When link told you link: file2.txt: File exists, that was actually an error message. Because a file file2.txt already existed, the link command was unable to create a link by that name. Thus file1.txt and file2.txt are still separate files, and that is how they are able to have different contents.

The link command does not create a relationship between separate files. It creates another name for the very same file. That name may be different, or reside in a different directory, or both, but it has the same relationship to the file as its original name. A common though somewhat imprecise shorthand you may have heard for this is that "a hard link is the file."

Links and Inodes

Although it's intuitive to many users that every file exists in a particular directory and nowhere else, and has just one name, those things are not true. Instead:

  • The contents of a file may be physically spread out throughout the disk.
  • Metadata about where to find the file's contents, as well as the owner, group owner, permissions, and any extended attributes of the file, are stored in a data structure called an inode. (An inode also contains some other information.)
  • For each distinct file there is exactly one inode, and each inode is identified with a number. This inode number is the number shown in the left column when you run ls -li (and not at all when you merely run ls -l). Two different files residing on the same device always have different inode numbers.
  • It is useful to be able to think of a file as having a name, and as residing somewhere in a directory hierarchy. Therefore, a file may have one or more links (also called hard links, since there is something else called a "soft" or "symbolic" link). Each link has exactly one name and location. A file's links are links to the inode.
  • A file's inode contains a count of how many links to it currently exist. When a new link is created, this count is incremented; when a link is removed, it is decremented. When it is decremented to zero -- that is, when the last link is removed -- then the file has been deleted.
  • The ln (without -s), cp -l, and link commands create an additional link to an existing file. For example, link file1.txt file2.txt requires that a link file1.txt already exist and that no link file2.txt exist, and it creates a new link file2.txt to the same file that file2.txt links to. Most of the time it is sufficient to say that "file2.txt is a link to file1.txt." It is equally correct to say, "file1.txt is a link to file2.txt." Internally neither points to the other, but instead both point to the same inode.
  • The rm and unlink commands remove links. When we run rm foo, we tend to think of this as deleting foo, but no data in a file is lost and no disk space corresponding to the file is freed until all links to a file are removed. Often a file has just one link, but not always.

    (Remember, however, that a symbolic link is not the same thing as a hard link. A symlink to a file does not prevent data loss when the file is deleted!)

Making Another Link to a File

To successfully experiment with hard links, you can ensure file1.txt does exist and file2.txt does not exist. Then when you run link file1.txt file2.txt, you will have two links, file1.txt and file2.txt. When you run ls -li you will see that they have the same inode number.

Now file1.txt and file2.txt are the same file.

Finally, you may want to use ln instead of link. The ln command is more commonly used, safeguards against some errors, and, on some systems, has nicer error messages. (When you use the ln command without the -s flag, it creates hard links, as does the link command. Passing the -s flag causes to create a symbolic link instead.)

Further Reading


It depends on how you added that text. If you typed echo foo >> file, you still have a single file. Some text editors will delete the original file or rename it to make a backup, which will break the link or leave the link connecting to the backup.

  • If I understand correctly link and ln without any options will do the same thing, create a hard link, pointing to the same inode. You can see that with the command ls -iltr file1.txt file2.txt. You explain in the answer, that some tools will delete the original file or rename it to make a backup and use a new inode for the edited file. Please tell us which tool will work like that, and if possible, a tool that 'preserves the hard link to the file name (and not to a backup file)'. – sudodus Jan 19 '17 at 12:12
  • I cannot catalog the behavior of all tools. Experiment with the tools available to you. If the tool makes a backup copy, it probably breaks the link. – stolenmoment Jan 20 '17 at 3:34
  • I did not ask for a catalog of all tools, only two examples, one that 'breaks the link', and one that 'preserves' it. – sudodus Jan 20 '17 at 5:50
  • Here are some obvious choices: "echo > onefilename" and "echo >> otherfilename" will preserve the links, either replacing or appending the contents. vi (really vim.tiny) preserves the links. "sed -i" (surprisingly) breaks the links. – stolenmoment Jan 20 '17 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.