What is the difference between a symbolic link and a hard link?

Question

Recently I was asked this during a job interview. I was honest and said I knew how a symbolic link behaves and how to create one, but do not understand the use of a hard link and how it differs from a symbolic one.

Thermodynamics

about 'do not understand the use of a hard link', it can be used in build systems which do lot of copying of binaries. Creating hard link instead of actual copy speeds things up. MSBuild 4.0 supports this. – Affliction

I find this link very useful to understand it. askubuntu.com/questions/108771/… – Show

unix.stackexchange has a good list of bullet points... very helpful because it lays out all the constraints very concisely and is easy to skim. (lots of these bullet points cover edge cases/caveats that are only mentioned in the comments of this question... or aren't mentioned at all) – Theocrasy

youtube.com/watch?v=lW_V8oFxQgA – Futility

In addition to the answers here that explained the differences, I searched for when to use hard links vs symbolic links, and the answer to that also helped answer the difference.: https://mcmap.net/q/54115/-what-is-the-purpose-of-creating-a-symbolic-link-between-files – Photovoltaic

Answer 1

Underneath the file system, files are represented by inodes. (Or is it multiple inodes? Not sure.)

A file in the file system is basically a link to an inode.
A hard link, then, just creates another file with a link to the same underlying inode.

When you delete a file, it removes one link to the underlying inode. The inode is only deleted (or deletable/over-writable) when all links to the inode have been deleted.

A symbolic link is a link to another name in the file system.

Once a hard link has been made the link is to the inode. Deleting, renaming, or moving the original file will not affect the hard link as it links to the underlying inode. Any changes to the data on the inode is reflected in all files that refer to that inode.

Note: Hard links are only valid within the same File System. Symbolic links can span file systems as they are simply the name of another file.

Sitar

I'm sure the i-nodes depend on the particular variant of the OS; however, I believe it is usually a single i-node. The i-node has info about the file and info about where the data is stored on disk. Large files will have indirect pointers to additional tables. – Sargassum

You might want to add the useful feature that symbolic links can cross filesystems, hard links cannot (they must refer to a file on the same filesystem). – Ginetteginevra

There is a good visual explanation in an article on Linux Gazette – Iz

I also wrote a blog on that after some reading and experiments csharpbsharp.tumblr.com – Unionist

One more thing to add is that a link (or hard link) can not cross even partitions on the same disk. So, a link must be local to the file system. A soft link (or symbolic link), on the other hand, can cross any boundary (i.e. partition, disk) as long as it is local to the machine. – Hydro

What does span file system mean? Doesn't I can only own 1 file system under my Linux machine? – Tadtada

@Zen: You have one root. But you can mount filesystems anywhere in the tree. Each partition has its own filesystem and you can even mount filesystems from other machines with nfs etc... – Sitar

@LokiAstari. This morning I coincidentally used df -h and saw Filesystems and Mounted on column, suddenly I understand what's multiple filesystem. My / is mounted on /dev/xvda2, I guess I can't remount it to other disk blocks unless at the installation period of Linux? – Tadtada

And for my understanding, hard-link is another link pointed to the source of the previous file refers to, Like www.a.com and www.b.com both refers to test.html. And soft-link just point to a path, no matter what it is inside. Like www.c.com always redirect users to www.a.com, no matter how the content varies in www.a.com. Is my understanding accurate? – Tadtada

@zen: You can unmount/remount a file system any time it is not being used. For the root partition this is a bit tricky but it can be done (not recomended). To do it for the root it is usually best to boot of a rescuse CD first modify the mounts and re-boot. But you should ask this kind of question on super user. – Sitar

@zen: I don't like your DNS example as it adds too many other layers of indirection and depends how you interpret these layers. Personally I see all DNS as examples of soft links (if I change www.c.com from 10.10.10.10 to 10.10.10.11 it can still serve a file but it is not the same as the original file. A hard link is a link to the inode and thus explicitly the data. No matter what you do with the file the file always points at the same inode and thus the same data. – Sitar

Could you clarify what's the meaning of "..link to another name in the file system"? How can the name help accessing the intended inode? – Raincoat

@ThunderWiring: A symbolic link (soft link) is a link from one file name to another file name. When you open a symbolic link the file system follows the chain of links until it reaches a real file. Then it uses the real file to access the underlying iNode data. The command readlink -f <fileName> will follow a symbolic chain to the real file. – Sitar

Why can directories not be used as the source file for hard links? – Darindaring

See <Unix Programming Environment> book for detail explanation of inode. – Ceiba

That Linux Gazette article mentioned in the comment above is incredibly helpful. Thanks, @Iz ! – Sidelong

Perhaps this is mere pedantry, but I think the statement "deleting renaming or moving the original file will not affect the hard link as it links to the underlying inode" is misleading. Deleting the original link to the file will not have an affect on other links to the file, but deleting the file absolutely has an impact on all links to it. It's not typically possible to delete the file without removing all links from the file system, but (for example), if you took a large magnet and deleted the data from all of the blocks of the file, all links would be affected. – Lei

IOW, the first link to a file isnot the file. If you create a file with touch foo, and then create a second link with ln foo bar, and then delete the original link with rm foo, you have not deleted the "original file" because "foo" is not the file. foo is just the first hard link to the file. – Lei

@WilliamPursell: Would changing: deleting renaming or moving the original file to deleting renaming or moving the original 'file system' file satisfy your pedantry? I personally think I cover this two lines above with: When you delete a file it removes one link to the underlying inode. but I am happy to update the wording if you want to give me some specific pointers on better wording. – Sitar

I think a better wording would be deleting, renaming, or moving the original link to the file. – Lei

@WilliamPursell I see were you are coming from. But a user of the file system does not look at it like a link (a link implies a symbolic link from the perspective of the file system). From there perspective they are working with files. Just because underneath the File System is another system that actually stores the file. How about deleting, renaming, or moving the original file (hard link to the inode) I have to ware my pedant hat too. – Sitar

You haven't said what a "name" is. I believe you mean "file" according to the explanation you gave for hard links. Upvoting the answer below as it makes things clearer using a diagram – Boswall

Answer 2

As the saying goes, a picture is worth a thousand words. Here is how I visualize it:

Here is how we get to that picture:

1. Create a name myfile.txt in the file system that points to a new inode (which contains the metadata for the file and points to the blocks of data that contain its contents, i.e. the text "Hello, World!":

   $ echo 'Hello, World!' > myfile.txt
   

2. Create a hard link my-hard-link to the file myfile.txt, which means "create a file that should point to the same inode that myfile.txt points to":

   $ ln myfile.txt my-hard-link
   

3. Create a soft link my-soft-link to the file myfile.txt, which means "create a file that should point to the file myfile.txt":

   $ ln -s myfile.txt my-soft-link
   

Look what will now happen if myfile.txt is deleted (or moved): my-hard-link still points to the same contents, and is thus unaffected, whereas my-soft-link now points to nothing. Other answers discuss the pros/cons of each.

Bambibambie

Could you explain how a file can point to another file? How can this be interpreted in terms of Inodes for both files? – Raincoat

@Raincoat By "point", I mean whatever the link references. In the case of a hard link, it references an inode directly (i.e. the same inode that is referenced by myfile.txt). For the soft link, it's reference is not the inode (which contains the data), but rather it's reference is the file system path to myfile.txt (e.g. /home/Documents/myfile.txt) – Bambibambie

Maybe I'm slow, but your picture just cleared up 20 years of mystery in about 2 seconds. – Morion

I've been trying to formalize this for some time so I can explain it to a colleague. This is the clearest answer that illustrates the first one. Thank you :-) – Valiancy

Most useful answer, I'm mad this is buried so deeply in this post. I would give you a hundred internet points but sadly I can only give you one. – Horizon

"Here is how I visualize it:" Is it really your visualization? Just asking, because I found the exact same picture here – Amandy

@user463035818 Yes, I made that visualization myself in Keynote. The author of that article just copied the image. Also, that article was published in 2017, whereas my answer was published in 2015. – Bambibambie

i didnt want to accuse you, its just easier to comment and get feedback here than on a blog. I am quite allergic to "just copying" stuff so i wanted to know who was first (could have compared the dates, but wasnt clever enough ;) – Amandy

actually i dont care about legal issues, but i feel fooled when reading something that (implicitly) claims that its original work – Amandy

Probably the best explanation man...and and this answer should be as accepted answer. – Cabasset

The illustration in this answer combined with the description in the accepted answer helped me. – Dm

Could someone expand this picture for how directories relate to the entries on this graph? – Falmouth

Answer 3

Some examples that might help.

Create two files with data in them:

$ printf Cat > foo
$ printf Dog > bar

Create a hard and soft (aka symbolic) link:

$ ln foo foo-hard
$ ln -s bar bar-soft

List directory contents in long format by increasing size:

ls -lrS
lrwxr-xr-x   1 user  staff        3  3 Apr 15:25 bar-soft -> bar
-rw-r--r--   2 user  staff        4  3 Apr 15:25 foo-hard
-rw-r--r--   2 user  staff        4  3 Apr 15:25 foo
-rw-r--r--   1 user  staff        4  3 Apr 15:25 bar

This tell us that

• 1st column: the file mode for the soft and hard links differ

  • soft link: lrwxr-xr-x
    • filetype: l = symbolic link
    • owner permissions: rwx = readable, writable, executable
    • group permissions: r-x = readable, not writable, executable
    • other permissions: r-x = readable, not writable, executable
  • hard link: -rw-r--r--
    • filetype: - = regular file
    • owner permissions: rw- = readable, writable, not executable
    • group permissions: r-- = readable, not writable, not executable
    • other permissions: r-- = readable, not writable, not executable

• 2nd column: number of links is higher for the hard linked files

• 5th column: the size of the soft link is smaller, because it's a reference as opposed to a copy

• last column: the symbolic link shows the linked-to file via ->

Changing the filename of foo does not affect foo-hard:

$ mv foo foo-new
$ cat foo-hard
Cat

Changing the contents of foo is reflected in foo-hard:

$ printf Dog >> foo
$ cat foo-hard
CatDog

Hard links like foo-hard point to the inode, the contents, of the file.

This is not the case for soft links like bar-soft:

$ mv bar bar-new
$ ls bar-soft
bar-soft
$ cat bar-soft  
cat: bar-soft: No such file or directory

The contents of the file could not be found because the soft link points to the name, that was changed, and not to the contents.

Likewise, If foo is deleted, foo-hard still holds the contents; if bar is deleted, bar-soft is just a link to a non-existing file.

Delvecchio

does this imply that a "file" and a "hard link" are the same, both pointing to an inode? on deleting file or hard link, the contents still exist as long as one is still pointing to the inode right? – Adminicle

@DanFromGermany Correct. The content is reachable as long as at least one hard link (i.e., file) is pointing at it. – Delvecchio

@Bibhas Copying a file duplicates the entire inode hierarchy of the original file. – Delvecchio

touch blah1; touch blah2 can be shortened to touch blah1 blah2 – Bullyboy

@DmitriZaitsev True, but it will be less readable for beginners IMO. – Delvecchio

I think this is best-understandable answer with respect to many answers I've read. A sample is better than bunch of explanation text. – Agraphia

You can also run ls -lia to see the actual inode# associated with each file. – Walkon

Answer 4

Hard links are useful when the original file is getting moved around. For example, moving a file from /bin to /usr/bin or to /usr/local/bin. Any symlink to the file in /bin would be broken by this, but a hardlink, being a link directly to the inode for the file, wouldn't care.

Hard links may take less disk space as they only take up a directory entry, whereas a symlink needs its own inode to store the name it points to.

Hard links also take less time to resolve - symlinks can point to other symlinks that are in symlinked directories. And some of these could be on NFS or other high-latency file systems, and so could result in network traffic to resolve. Hard links, being always on the same file system, are always resolved in a single look-up, and never involve network latency (if it's a hardlink on an NFS filesystem, the NFS server would do the resolution, and it would be invisible to the client system). Sometimes this is important. Not for me, but I can imagine high-performance systems where this might be important.

I also think things like mmap(2) and even open(2) use the same functionality as hardlinks to keep a file's inode active so that even if the file gets unlink(2)ed, the inode remains to allow the process continued access, and only once the process closes it does the file really go away. This allows for much safer temporary files (if you can get the open and unlink to happen atomically, which there may be a POSIX API for that I'm not remembering, then you really have a safe temporary file) where you can read/write your data without anyone being able to access it. Well, that was true before /proc gave everyone the ability to look at your file descriptors, but that's another story.

Speaking of which, recovering a file that is open in process A, but unlinked on the file system revolves around using hardlinks to recreate the inode links so the file doesn't go away when the process which has it open closes it or goes away.

Resiniferous

Answer 5

Soft Link:

soft or symbolic is more of a short cut to the original file....if you delete the original the shortcut fails and if you only delete the short cut nothing happens to the original.

Soft link Syntax: ln -s Pathof_Target_file link

Output : link -> ./Target_file

Proof: readlink link Also in ls -l link output you will see the first letter in lrwxrwxrwx as l which is indication that the file is a soft link.

Deleting the link: unlink link

Note: If you wish, your softlink can work even after moving it somewhere else from the current dir. Make sure you give absolute path and not relative path while creating a soft link. i.e.(starting from /root/user/Target_file and not ./Target_file)

Hard Link:

Hard link is more of a mirror copy or multiple paths to the same file. Do something to file1 and it appears in file 2. Deleting one still keeps the other ok.

The inode(or file) is only deleted when all the (hard)links or all the paths to the (same file)inode has been deleted.

Once a hard link has been made the link has the inode of the original file. Deleting renaming or moving the original file will not affect the hard link as it links to the underlying inode. Any changes to the data on the inode is reflected in all files that refer to that inode.

Hard Link syntax: ln Target_file link

Output: A file with name link will be created with the same inode number as of Targetfile.

Proof: ls -i link Target_file (check their inodes)

Deleting the link: rm -f link (Delete the link just like a normal file)

Note: Symbolic links can span file systems as they are simply the name of another file. Whereas hard links are only valid within the same File System.

Symbolic links have some features hard links are missing:

• Hard link point to the file content. while Soft link points to the file name.
• while size of hard link is the size of the content while soft link is having the file name size.
• Hard links share the same inode. Soft links do not.
• Hard links can't cross file systems. Soft links do.

• you know immediately where a symbolic link points to while with hard links, you need to explore the whole file system to find files sharing the same inode.

  # find / -inum 517333

  /home/bobbin/sync.sh
  /root/synchro
  

• hard-links cannot point to directories.

The hard links have two limitations:

• The directories cannot be hard linked. Linux does not permit this to maintain the acyclic tree structure of directories.
• A hard link cannot be created across filesystems. Both the files must be on the same filesystems, because different filesystems have different independent inode tables (two files on different filesystems, but with same inode number will be different).

Leena

"while size of hard link is the size of the content while soft link is having the file name size." Just to clarify, making another hard link does only affect the free space by a few bytes. – Officeholder

Answer 6

A simple way to see the difference between a hard link and a symbolic link is through a simple example. A hard link to a file will point to the place where the file is stored, or the inode of that file. A symbolic link will point to the actual file itself.

So if we have a file called "a" and create a hard link "b" and a symbolic link "c" which all refer to file "a" :

echo "111" > a
ln a b
ln -s a c

The output of "a", "b", and "c" will be :

cat a --> 111
cat b --> 111
cat c --> 111

Now let's remove file "a" and see what happens to the output of "a", "b", and "c":

rm a
cat a --> No such file or directory
cat b --> 111
cat c --> No such file or directory

So what happened?

Because file "c" points to file "a" itself, if file "a" is deleted then file "c" will have nothing to point to, in fact it is also deleted.

However, file "b" points to the place of storage, or the inode, of file "a". So if file "a" is deleted then it will no longer point to the inode, but because file "b" does, the inode will continue to store whatever contents belonged to "a" until no more hard links point to it anymore.

Bodega

It might be helpful to point that, a file is a very abstract object and has with all abstract things, the real intent of high level implementations can fall short of proper explanation without risking blowing off abstractions. – Interim

Is hardlink slower than symbolic link? Since hardlink work like copying – Mutant

Answer 7

Symbolic links link to a path name. This can be anywhere in a system's file tree, and doesn't even have to exist when the link is created. The target path can be relative or absolute.

Hard links are additional pointers to an inode, meaning they can exist only on the same volume as the target. Additional hard links to a file are indistinguishable from the "original" name used to reference a file.

Hagar

Also, when you remove the file you link to, a symbolic link gets broken, a hard link remains valid, because it "keeps" the file in the file system. – Bavaria

Answer 8

I would point you to Wikipedia:

• Symbolic link
• Hard link

A few points:

• Symlinks, unlike hard links, can cross filesystems (most of the time).
• Symlinks can point to directories.
• Hard links point to a file and enable you to refer to the same file with more than one name.
• As long as there is at least one link, the data is still available.

Tressietressure

In theory (and in some cases even in practice) hard links can point to directories as well (in fact "." is a hard link to the current directory and ".." is a hard link to the parent directory). But they can be dangerous, so most UNIXes don't allow them (or require you to take special steps to take it). Apple uses them for their time machine implementation for example: earthlingsoft.net/ssp/blog/2008/03/x5_time_machine – Rarity

You are pointing to a link to an article... does that make you a symbolic link? – Buerger

@JoachimSauer Do you think that the new Apple file system will eliminate the need for Time Machine to use hard links to directories? – Endymion

I found wikipedia's explanation significantly shorter and more concrete than explanations in best-rated answers. – Watermelon

Answer 9

Hard link Vs Soft link can be easily explained by this image.

Artel

I guess your soft link pic is not right. Point: the inode of soft link should not point to the inode of original file. Cause if you rename the original file , the related soft link is dead – Bonnie

@Bonnie yes you are right - but I still find it a very nice and intuitive explanation. Just imagine that the arrow between inodes isn't there... – Puckery

Answer 10

Hard links are very useful when doing incremental backups. See rsnapshot, for example. The idea is to do copy using hard links:

• copy backup number n to n + 1
• copy backup n - 1 to n
• ...
• copy backup 0 to backup 1
• update backup 0 with any changed files.

The new backup will not take up any extra space apart from any changes you've made, since all the incremental backups will point to the same set of inodes for files which haven't changed.

Carrol

Answer 11

From MSDN,

Symbolic link

A symbolic link is a file-system object that points to another file system object. The object being pointed to is called the target.

Symbolic links are transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner.

Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented its symbolic links to function just like UNIX links.

Symbolic links can either be absolute or relative links. Absolute links are links that specify each portion of the path name; relative links are determined relative to where relative–link specifiers are in a specified path

An example of Absolute Symbolic Link

X: "C:\alpha\beta\absLink\gamma\file"
Link: "absLink" maps to "\\machineB\share"
Modified Path: "\\machineB\share\gamma\file"

An example of Relative Symbolic Links

X: C:\alpha\beta\link\gamma\file
Link: "link" maps to "..\..\theta"
Modified Path: "C:\alpha\beta\..\..\theta\gamma\file"
Final Path: "C:\theta\gamma\file"

Hard link

A hard link is the file system representation of a file by which more than one path references a single file in the same volume.

To create a hard link in windows, navigate to where link is to be created and enter this command:

mklink /H Link_name target_path

Note that you can delete hard links any order, regardless of the order in which they were created. Also, hard links can not be created when

• references are in different local drives
• references include network drive. In other words, one of the references is a network drive
• hard link to be created is in the same path as the target

Junction

NTFS supports another link type called junction. MSDN defines it as follows:

A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer. Otherwise, junctions operate identically to hard links.

The bolded parts in hard link section and junction section show the basic difference between the two.

Command to create a junction in windows, navigate to where link is to be created and then enter:

mklink /J link_name target_path

Stagner

Answer 12

Simply , Hard link : is just add new name to a file, that's mean , a file can have many name in the same time, all name are equal to each other, no one preferred, Hard link is not mean to copy the all contents of file and make new file is not that, it just create an alternative name to be known..

Symbolic link (symlink) : is a file pointer to another file, if the symbolic link points to an existing file which is later deleted, the symbolic link continues to point to the same file name even though the name no longer names any file.

Merola

Answer 13

This answers is for Web Developers 🙃:

Hard Link: like pointing different domain names to the same host

* abc.com and def.com -> points to the IP 1.2.3.4
* abc.com and def.com -> files in linux
* IP -> inode in linux
* By deleting the domain abc.com users still access your website through def.com or vice versa
* Mutation through abc.com will affect def.com and vice verca

Sym Link : redirecting one domain to another domain

* accessing abc.com will redirect to def.com as you've accessed def.com directly
* removing the def.com domain will break the link abc.com

Johan

in your Sym link example, removing abc.com, will it also remove def.com or 1.2.3.4 completely? – Footlights

Answer 14

Also:

1. Read performance of hard links is better than symbolic links (micro-performance)
2. Symbolic links can be copied, version-controlled, ..etc. In another words, they are an actual file. On the other end, a hard link is something at a slightly lower level and you will find that compared to symbolic links, there are less tools that provide means for working with the hard links as hard links and not as normal files

Indistinctive

Answer 15

What you think of as an ordinary "file" is actually two separate things: The data of a file, and a directory entry. When you create a hard link for a file, you actually create a second directory entry which refers to the same data. Both directory entries have the exact same functionality; each one can be used to open the file to read it. So you don't really have "a file plus a hard link", you have "file data with two directory entries". What you think of as deleting a file actually deletes a directory entry, and when the last directory entry for the data is deleted, then the data itself is deleted as well. For ordinary files that have only one directory entry, deleting the directory entry will delete the data as always. (While a file is opened, the OS creates a temporary link to the file, so even when you delete all directory entries, the data stays but disappears as soon as you close the file).

As an example, create a file A.txt, a hard link B.txt, and delete A.txt. When you created A.txt, some data was created, and a directory entry A.txt. When you created the hard link, another directory entry B.txt was created, pointing to the exact same data. When you delete A.txt, you still have all the data and a single directory entry B.txt, exactly as if you had create a file B.txt in the first place.

A soft link is just an (almost) ordinary file, except that it doesn't contain data, but the path of another directory entry. If you delete the file that the soft link refers to, then the soft link will contain a path that doesn't point to a directory entry anymore; it is broken. If you delete the soft link, it's like deleting any other file, the file it points to is unaffected.

Airwaves

Answer 16

A directory entry is link a structrue:

struct dentry{
    ino_t ino;
    char  name[256];
}

the ino is the number of inode, the name is the file name, inode structure maybe like：

struct inode{
      link_t nlink; 
      ...
}

for example you creat a file /1, the directory entry maybe like:

struct dentry{
     ino_t ino; /* such as 15 */
     char  name[256]; /* "1" */
} 

the inode struct maybe like:

   struct inode{ /* inode number 15 */
         link_t nlink; /* nlink = 1 */
         ...
    }

then you create a hard link(may be /100), the directory entry maybe like:

  struct dentry{
     ino_t ino; /* 15 */
     char  name[256]; /* 100 */
  }

the inode struct maybe like:

   struct inode{ /* inode numebr 15 */
         link_t nlink; /* nlink = 2 */
         ...
    }

then you create a symbolic link(may be /200) to file 1, the directory entry maybe like:

  struct dentry{
        ino_t ino; /* such as 16 */
        char  name[256]; /* "200" */
  }

the inode struct maybe like:

   struct inode{ /* inode number 15 */ 
         link_t nlink; /* nlink = 2 */
         ...
    }

   struct inode{ /* inode number 16 */
         link_t nlink; /* nlink = 1 */
         ...
    } /* the data of inode 16 maybe /1 or 1 */

Curcio

Answer 17

My two cents on usage:

Soft links may be used to shorten long path names, i.e.:

ln -s /long/folder/name/on/long/path/file.txt /short/file.txt

Changes made to /short/file.txt will be applied on the original file.

Hard links may be used to move around big files:

$ ls -lh /myapp/dev/
total 10G
-rw-r--r-- 2 root root 10G May 22 12:09 application.bin

ln /myapp/dev/application.bin /myapp/prd/application.bin

Instant copy to different folder, and original file (on /myapp/dev) may be moved or deleted, without touching the file on /myapp/prd

Exurb

Answer 18

Adding to all the above answers, the difference in finding the hardlink and softlink file can be understood as below:

I have a file f6 in my current directory, as well as a directory named t2.

File named f1 and ./t2/f2 are symbolic links to f6.

File named f7 and ./t2/f8 are hard links of f6.

To find soft as well as hard link we can use:

$ find -L . -samefile f6 

> ./f1
> ./f6
> ./f7
> ./t2/f2
> ./t2/f8

To find only hardlink we can use:

$ find . -xdev -samefile f6

> ./f6
> ./f7
> ./t2/f8

Since hardlinks can be created on the same file system, we can search all the hardlinks without -L option used (with -xdev option) in the same file-system/mount-point. It saves the unnecessary search into different mount points.

So searching the hardlink is somewhat faster then searching the softlinks(Please rectify if I am wrong or not clear).

Ergotism

Answer 19

Symbolic links give another name to a file, in a way similar to hard links. But a file can be deleted even if there are remaining symbolic links.

Contempt

No. The symlink is not "another name for the same file", it is a file in its own right, linking to the target file. – Amianthus

Answer 20

I just found an easy way to understand hard links in a common scenario, software install.

One day I downloaded a software to folder Downloads for install. After I did sudo make install, some executables were cped to local bin folder. Here, cp creates hard link. I was happy with the software but soon realized that Downloads isn't a good place in the long run. So I mved the software folder to source directory. Well, I can still run the software as before without worrying about any target link things, like in Windows. This means hard link finds inode directly and other files around.

Stenosis

Answer 21

IN this answer when i say a file i mean the location in memory

All the data that is saved is stored in memory using a data structure called inodes Every inode has a inodenumber.The inode number is used to access the inode.All the hard links to a file may have different names but share the same inode number.Since all the hard links have the same inodenumber(which inturn access the same inode),all of them point to the same physical memory.

A symbolic link is a special kind of file.Since it is also a file it will have a file name and an inode number.As said above the inode number acceses an inode which points to data.Now what makes a symbolic link special is that the inodenumbers in symbolic links access those inodes which point to "a path" to another file.More specifically the inode number in symbolic link acceses those inodes who point to another hard link.

when we are moving,copying,deleting a file in GUI we are playing with the hardlinks of the file not the physical memory.when we delete a file we are deleting the hardlink of the file. we are not wiping out the physical memory.If all the hardlinks to file are deleted then it will not be possible to access the data stored although it may still be present in memory

Repeal

Answer 22

hard link is unix like it is old one use in unix and then linux but symbolick link is new in linux.

hard link inode is same as original file inode. But symbolik link inode is different from original file inode.

Hard link file size in byte is same as original file size in byte. But symbolik link file size in byte is not as the original file size in byte. symbolick link file size is smaller then original file size.

Hard link is a mirror copy of original file . symbolick link or softlink is like shortcut in windows.

If you delete original file, hard link will remain its file and you can see hard link file content . In symbolick link, if you delete original file its symbolic link will broken and symbolick link still remain but it can not show symbolick link content.

Symbolick link is new and it is have many feature but hard link is old one thats why it is have less feature.

lets make some hard and symbolick link using terminal : echo "why so serious" > file.txt

hard link: ln file.txt file_hard

symbolick link: ln -s file.txt file_sym

lets see there content with inode : ls -li

Her

Answer 23

I just found an easy way to understand hard links in a common scenario, software install.

One day I downloaded a software to folder Downloads for install. After I did sudo make install, some executables were cped to local bin folder. Here, cp creates hard link. I was happy with the software but soon realized that Downloads isn't a good place in the long run. So I mved the software folder to source directory. Well, I can still run the software as before without worrying about any target link things, like in Windows. This means hard link finds inode directly and other files around.

Sophy

This answer is literally copied word for word from @themefield's answer from 2017. – Ezaria