Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

When would you use one over the other?

share|improve this question
3  
I don't feel like copying my server fault answer: serverfault.com/questions/10543/… –  dmckee Mar 19 '11 at 2:13
add comment

7 Answers 7

up vote 10 down vote accepted

The different semantics between hard and soft links make them suitable for different things.

Hard links:

  • 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 -l will 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)
share|improve this answer
1  
Nice list. Just wanted to add that you can also break a relative path symlink by moving the symlink itself. –  jw013 Oct 25 '11 at 3:50
add comment

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!

share|improve this answer
    
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. –  ultrasawblade Mar 18 '11 at 19:01
2  
Is it really very bad? What will happen? The most excitement I'm able to recreate is "Too many levels of symbolic links" error messages. –  mattdm Mar 18 '11 at 19:05
1  
ls -l is enough to see what is being linked by a symlink, the a stands for --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. –  D4RIO Mar 18 '11 at 19:37
3  
Windows 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. –  Gilles Mar 18 '11 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 1 shows that the symlink 1 is 5 bytes long, whereas ln -s /usr/share/ 2; ls -l 2 showas that 2 is 11 bytes long. –  daniel kullmann Jan 20 '12 at 17:48
add comment

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.

share|improve this answer
4  
Maybe 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. –  D4RIO Mar 18 '11 at 19:04
1  
Think 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. –  geekosaur Mar 18 '11 at 19:09
    
Thanks, then incremental backup systems are pretty similar to version control systems this way =D –  D4RIO Mar 18 '11 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 –  Dmitry Pashkevich Mar 1 '13 at 16:00
add comment

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.

Cheers

share|improve this answer
    
Are the performance benefits to using hard links? Or, why would you ever use a hard link instead of a symlink? –  ripper234 Mar 18 '11 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.) –  geekosaur Mar 18 '11 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 stat will fail. –  D4RIO Mar 18 '11 at 19:12
    
@geekosaur: I'm adding your answer to mine since it's very useful –  D4RIO Mar 18 '11 at 19:16
    
No problem. I actually started to write it as a comment to yours, but comments are too short. –  geekosaur Mar 18 '11 at 19:18
show 3 more comments

"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
share|improve this answer
    
Thanks, I understand now!! –  LatinUnit Dec 11 '11 at 14:31
    
But what's a practical use-case for this? –  ewwhite Dec 11 '11 at 15:10
    
One 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. –  bdowning Dec 11 '11 at 16:16
    
practical 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. –  bdowning Dec 11 '11 at 16:30
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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