When would you use one over the other?
The different semantics between hard and soft links make them suitable for different things.
- indistinguishable from other directory entries, because every directory entry is hard link
- "original" can be moved or deleted without breaking other hard links to the same inode
- only possible within the same filesystem
- permissions must be the same as those on the "original" (permissions are stored in the inode, not the directory entry)
- can only be made to files, not directories
Symbolic links (soft links)
- simply records that point to another file path. (
ls -lwill show what path a symlink points to)
- will break if original is moved or deleted. (In some cases it is actually desirable for a link to point to whatever file currently occupies a particular location)
- can point to a file in a different filesystem
- can point to a directory
- on some file system formats, it is possible for the symlink to have different permissions than the file it points to (this is uncommon)
1Nice list. Just wanted to add that you can also break a relative path symlink by moving the symlink itself.– jw013Oct 25, 2011 at 3:50
5"[E]very directory entry is hard link." That's an excellent point that I've never seen expressed before, but I worry that someone just beginning to wrap his or head around links won't get it. For those in this situation, here's a hint: The layout of files and directories that you see when running the ls command isn't exactly the same thing as the storage system it represents. Hard links are references to an individual file on the storage system. A file is stored once. Read up on "inodes."– MarioJun 12, 2015 at 19:32
@Mario: yup. Every directory entry links a name to an inode. The system call for deleting a filename is even called
unlink(2). "normal" files (with a link count of 1) are just a special case. If it helps, you can think of inodes as objects, and names as ref-counted pointers (the inode's link count is the reference-count). Aug 29, 2015 at 22:53
1You could think of a symbolic link as a text file with a name in it. It is interpreted as a symbolic link because of a special flag to the file. Hard link examples you know are
..– Ned64Aug 30, 2015 at 13:28
1here is another answer that explains why hard links can't be made to directories. I find this answer helpful because it is more concise and easier to read. Dec 2, 2016 at 14:10
The point of both types of links is to provide a way to make a file appear in two locations at the same time. This has a lot of uses. 9 times out of 10 you want to use symbolic links.
Symbolic links, or "symlinks" work a little like Windows shortcuts. The contents of a symlink are a pointer to the real location of the file/directory. If you delete the real file, the symlink will become "dangling," and won't work. Deleting the symlink does not delete the real file. You can have as many symlinks to a single file (or even other symlinks) as you like.
Unlike Windows though, they work on the filesystem level, not shell or application level, so pretty much any application will "follow" symlinks as expected.
ls -al can be used as a quick way to see where symlinks "point" to.
Hardlinks work even on a lower level. A hardlink is an actual, physical on-the-filesystem-level directory entry of the file. Technically, a directory entry is a hardlink, thus each file has at least one hardlink in a directory somewhere. Hardlinks are not separate from the file they point to; if a file has multiple hardlinks in different directories, deleting the hardlink with utilities like
rm won't truly delete the file, until all hardlinks are gone.
I can't think of situation where use of hardlinks is common, or even needed, unless you intentionally want to prevent the files from getting deleted or are doing some weird low-level work with partitions or other filesystem related things. EDIT: There's great ideas in the other answers to this question, though!
Also, symlinks have permissions like normal files, but the operating system doesn't consult them, it consults the permissions targeted file instead to decide behavior. And, don't do circular chains of symlinks. Very bad. Mar 18, 2011 at 19:01
3Is it really very bad? What will happen? The most excitement I'm able to recreate is "Too many levels of symbolic links" error messages.– mattdmMar 18, 2011 at 19:05
ls -lis enough to see what is being linked by a symlink, the
--all, see manpage. And even if symlinks work at the file system, there are alternative functions to use symbolic links as files instead of follow. Mar 18, 2011 at 19:37
4Windows shortcuts are actually quite different from symlinks: they follow their target, and they are also regular files. (Windows also has symlinks, but they're not used much.) Symlinks are purely textual, the target text is read whenever you access the file. Whether symlink permissions matter depends on the OS and filesystem. Mar 18, 2011 at 20:04
AFAIK, the content of a symlink file is the path the symlink points to, which can be seen when looking at the size of the symlink file:
ln -s /home 1; ls -l 1shows that the symlink 1 is 5 bytes long, whereas
ln -s /usr/share/ 2; ls -l 2showas that 2 is 11 bytes long. Jan 20, 2012 at 17:48
Hard links are very useful for disk-based backup mechanisms, because you can have a full directory tree for each backup while sharing the space for files that haven't changed — and the filesystem keeps track of reference counting, so when the last reference to a given version goes away because the backup was expired/removed for space reasons, the space it used is automatically reclaimed. Some mail clients also use it for messages filed to multiple folders, for the same reason.
6Maybe disk-based version control mechanisms? If you hardlink something, then it's not a backup. If the original file gets corrupted, every hardlink to it gets corrupted too. Mar 18, 2011 at 19:04
1Think of incremental backup systems like Apple's Time Machine. (It should be obvious that these aren't disaster recovery type backups, but "oops, I deleted that file by accident" backups.) All unchanged files in an incremental backup are hardlinked together; when the file is changed, the next incremental copies it instead of linking to the previous version. Mar 18, 2011 at 19:09
Thanks, then incremental backup systems are pretty similar to version control systems this way =D Mar 18, 2011 at 19:22
But how does the incremental backup mechanism preserve the "old" version of a file? 1) Backup A created, it hardlinked file F; 2) File F modified; 3) next day Backup B created... Looks like I don't get something Mar 1, 2013 at 16:00
A soft link points to another pathname. That pathname may or may not actually exist. The path isn't looked for until you access the symlink. If the path doesn't exist when you try to access it, you have a broken symlink.
With a hard link, you have one file with multiple names. You can't say that one of those is the "real" file and the others are just a link to it. They are all equal. There's no such thing as a broken hard link the way there are broken symlinks.
Hard links work only within a single filesystem. If you want to link to a file on a different filesystem (e.g. a different partition or a network share), you must use a soft link.
Another big difference is what happens when you delete a linked file. If you delete one of a pair of hardlinked files, then create a new file with the same name, you'll have two separate files (the link is gone). If you delete the target of a symlink and create a new file with the same name, the link will point to the new file.
Hard links are just references to the same disk spaces, thath the 'why' you cannot hardlink something in other filesystem.
Symlinks are files linking other files (as Windows shortcuts), maybe in the same filesystem, maybe not.
EDIT: I will explain something more. Every file that exists has a minimum of 1 hard link. Hard links are the way to access the content of an inode of the filesystem. You can obtain the inode number of a file with
ls -i, and get the number of hardlinks with
stat as follows in this example:
$ stat plantilla-disenos.odt File: «plantilla-disenos.odt» Size: 12367 Blocks: 32 IO Block: 4096 fichero regular Device: 803h/2051d Inode: 319875 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ d4rio) Gid: ( 1000/ d4rio) Access: 2011-02-11 21:36:19.000000000 -0300 Modify: 2010-03-02 23:27:28.000000000 -0300 Change: 2010-04-10 17:46:27.000000000 -0300
Thanks @geekosaur for this reference:
The kernel has to restart pathname-to-inode translation (traversing the directory tree) to expand symlinks, whereas hard links all use the same inode. (You'll often see this referred to as namei, from the name of the kernel function that did this in traditional Unix.)
and this (edited):
Hard links are very useful for disk-based incremental backup mechanisms like Apple's Time Machine, because you can have a full directory tree for each backup while sharing the space for files that haven't changed — and the filesystem keeps track of reference counting, so when the last reference to a given version goes away because the backup was expired/removed for space reasons, the space it used is automatically reclaimed. Some mail clients also use it for messages filed to multiple folders, for the same reason.
Are the performance benefits to using hard links? Or, why would you ever use a hard link instead of a symlink? Mar 18, 2011 at 18:52
The kernel has to restart pathname-to-inode translation (traversing the directory tree) to expand symlinks, whereas hard links all use the same inode. (You'll often see this referred to as
namei, from the name of the kernel function that did this in traditional Unix.) Mar 18, 2011 at 18:57
@ripper234: Hardlinks are diskspace-saving solutions. You don't need to know about the filesystem to make a symlink, but you need to think before creating symlinks because you can create a loop or a long resolution path, so functions like
statwill fail. Mar 18, 2011 at 19:12
@geekosaur: I'm adding your answer to mine since it's very useful Mar 18, 2011 at 19:16
No problem. I actually started to write it as a comment to yours, but comments are too short. Mar 18, 2011 at 19:18
"hard" links share the same inode
$ touch foo $ ln foo foolink # Creates a hard link $ ls -li foo foolink 54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo 54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink
If I edit either foo or foolink there is only one file and it will be updated. If I remove only one of the filenames, the inode and data will persist, foolink will survive.
$ rm foo $ ls -li foo foolink ls: cannot access foo: No such file or directory 54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink
If I were to create the same, but with a "soft" or symbolic link, then There's one file, one inode, and a new file with its own inode pointing to the first.
$ touch foo $ ln -s foo foolink # Create symlink $ ls -li foo foolink 55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo 55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo
If I edit either foo or foolink there is still only one file and it will be updated.
If I remove only the symlink, the inode and data will persist. If I remove foo, the data will be gone, the symlink will persist but point to a non-existent file.
$ rm foo removed `foo' $ ls -l foo foolink ls: cannot access foo: No such file or directory lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo
1But what's a practical use-case for this?– ewwhiteDec 11, 2011 at 15:10
1One use, same as a "short cut" Another use, having multiple versions of an application on a system allows one to install, test new version, specifying app by full path, while symlink in bin points to production. After testing is complete change symlink to new version, leave old version in place for any users that have version dependent code. Think of perl, python, etc.– bsdDec 11, 2011 at 16:16
1practical use-case for hard links. At present on my filesystem I found a large number of hardlinks in /usr/share/zoneinfo Think of all the named files representing timezones, which are all identical to EST. We save filesystem space by not having redundant copies and allow for easier package management without having the management overhead of symlinks install/delete as packages are installed/deleted. Even if one is removed the original data is preserved. Sorry I didn't have time for a more pedantic explanation.– bsdDec 11, 2011 at 16:30
Hard links are additional directory entries for the same file. That means
- All hard links to a file must be on the same file system (because a directory entry cannot point to a file on a different file system), but not necessarily in the same directory.
- There's no difference between the original directory entry and the new hard link; from the operating system's view, they are just two directory entries to the same file. A file is only deleted if all of the hard links are deleted (and additionally, there's no process left that has that file still open).
- If you move/rename the "original", as long as you don't move it to another file system, the other hard links are not affected; they still point to the same file.
Many editors don't write the new content into the same file when saving, but rather do the following procedure:
- Write the new content to a new file.
- Rename the old file to a backup name (or, if not keeping backups of the previous file version, simply delete it).
- Rename the newly written file to the name of the previous file.
This scheme means that any other hard links to the same file will now no longer point to the current file, but to the previous version (this is true even in case the editor deletes the old file, because under Unix, "deleting" a file just means deleting its link; only if the deleted link is the only link the actual file gets deleted).
Since the hard link goes directly to the file, you can access that file even if you don't have access to the original location of that file (for example because you don't have any permissions on the directory the original entry is in). The only rights determining your access are the access rights of the file itself (which are associated with the file, not with the link; you cannot make hard links with different permissions for the same file) and the access rights for the path the hard link is contained in (basically, the execute rights the directory the link is in, and any direct and indirect parent directories).
Symbolic links, on the other hand, store the pathname (the name to the file — or rather its directory entry — potentially including its path, like
subdir/foo.bar) — of another file. If the pathname is relative, it's always interpreted relative to the directory the link is contained in. That means:
A symbolic link may refer to files on a different file system (even to a file system which does not itself support hard or soft links, like FAT).
If the original file is deleted, the symbolic link doesn't preserve the file content. Unless there are other hard links to the same file, the file content will be gone. The symbolic link will then be left dangling (that is, referring to a pathname that doesn't correspond to a directory entry). On the other hand, deleting the symbolic link doesn't affect the original file, since it only refers to its pathname.
If the original file is moved or renamed, the symbolic link is not updated, but left dangling. If you move the symbolic link, it only breaks if it contains a relative path, and the path is no longer valid from the new position.
If the original file is replaced by a new file with the same name (as in the editor scenario described above), the link refers to the new file.
Most uses of hard links are basically a way to have a copy of a file without having to store the file content twice. This works best if the files are never changed again, as otherwise it's easy to accidentally break the link (see the editor scenario above). There are, of course, cases where you want the link to be broken, as in the case of keeping several backups: For files that have changed in newer backups, you don't want the copy in older backups to change as well.
Normally if you want a link, you'll use a symbolic link. One example is when you move a directory to another partition (because the one it is on gets full), you can set a soft link from the old position to the new one, so any programs trying to access the directory at the old place will access it at the new place instead. This would not be possible with hard links. However be aware that symbolic links in the moved directory can break if they contain relative paths that lead out of the moved directory.
HARD LINK (Only Files) vs SOFT LINK (Files or Directories) vs BIND (HARD LINK for Directories)
While daxelrod's answer explains the question well, I thought that the picture in this case made a big difference, especially to beginners who don't understand inodes and complicated Linux jargon quite yet.
Think of this, if you "deleted" everything from your drive, you could run software to restore the data, because the 1's and 0's are still there, you just deleted all the Hard Links. Recovery Software's purpose is to rebuild the Hard Links to make sense of the 0's and 1's
I read a great "one liner" that made this all make sense and I wanted to share!
All files in Linux are "Hard Links" to the 0's and 1's on the disk. When you create a data (0's & 1's) the OS creates a Hard Link in the File Tree to reference that spot on the hard disk.
Create HARD LINK 2 and delete HARD LINK 1 Original File:
You may create another hard link and delete the original file, and you still have access to the newly created hard link.
Delete FILE(HARD LINK 1) that is SOFT LINKed to:
If you deleted the HARD LINK 1, do you think the SOFT LINK would work? No, The OS will report back that the HARD LINK 1 does not exist.
Delete SOFT LINK to HARD LINK:
In reverse, if you delete the SOFT LINK, will either HARD LINK work? Yes. As long as the OS has one HARD LINK File it will report that the fill has not been deleted.
-- Also worth researching/noting is BIND, a way to BIND two directories like symlinking two directories, but it is transparent to the OS (OS's can tell when you Symlink and some have rules regarding weather they can follow Symlinks). It uses Mount, not LS and can be configured via FSTAB.
1That's quite an ambitious effort, especially for a first post. Unfortunately, I believe that adding the material on "bind" (which wasn't asked for) just confuses matters; especially since you don't seem to have made much of an effort to explain "bind" mounting. Also, I understand hard and soft/symbolic links very well, and I barely understand your picture. I would be very surprised if a beginner could learn anything from it. Aug 29, 2015 at 7:27
While you can symlink directories, it shows in the file system as a symlink, if you BIND, it is transparent to the OS. Shows up just like a file. Aug 29, 2015 at 8:09
1(1) Actually, on at least some versions of Linux, you can bind mount a file. (2) While bind mounts look very similar to hard links, saying "Bind is simply the same as hard links (except you can't hard link a directory)" is simply wrong. Aug 29, 2015 at 14:34
@G-Man, agreed and removed, with just a note mentioning BIND Aug 30, 2015 at 8:23
@Free actually the soft link points to a file name (hard link 1) ; the schematics, should make this obvious.– JB.Aug 31, 2015 at 8:37
A hard link will keep a file on disk until all hard links to it, even the first (a "filename" is technically a hard link), have been deleted. A soft link can be left "dangling" until the file it point(s/ed) to is replaced.
This is a very old question but I have a use case that is requiring me to use hard links.
I'm a musician and so I have lots and lots and lots of audio files of various sorts on several hard drives attached to my Mac. Terabytes worth. I have them mostly organized very nicely with symlink directories so that I can find them by content publisher, style/sound, and other criteria based on how I'm thinking at the time. Unfortunately one program I use, Ableton Live, is completely incapable of viewing aliases or symlinks from its file browser. The only solution I've found is to create hard links of the directories I want it to be able to see into, and then everything works great.
So, this is another case of when you might need to use hard links, that might not have occurred to others.
I would file a bug report for Ableton Live. Maybe they're able to fix this. Jul 21, 2017 at 18:39
Yeah there is already a lot of complaining about this issue on abletons forums for years… They don't seem to be making any attempts to address it though I can't figure out why not.– JVCJul 21, 2017 at 20:07