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.
23 Answers
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.
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.
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.
I would point you to Wikipedia:
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.
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.
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
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
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.
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.
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
Related