原文:http://techthrob.com/2010/09/26/softlinks-vs-hardlinks-a-quick-explanation/
http://linuxgazette.net/105/pitcher.html
Q & A: The difference between hard and soft links
By Lew Pitcher
I participate in about 30 usenet newsgroups, and in a virtual LUG, anda number of questions keep coming up. I've answered a few of thesequestions often enough to have 'canned' an answer, which I modify,depending on the circumstances.
Here's one, now...
Q: Can someone give me a simple explanation of thedifference between a soft link and a hard link? The documentation I'veread mention these links but make no strong explanations of their meaningand how/when to use them. Thanks!
A: OK, I'll give it a try...
Unix files consist of two parts: the data part and the filename part.
The data part is associated with something called an 'inode'. The inodecarries the map of where the data is, the file permissions, etc. for thedata.
.---------------> ! data ! ! data ! etc / +------+ !------+ ! permbits, etc ! data addresses ! +------------inode---------------+
The filename part carries a name and an associated inode number.
.--------------> ! permbits, etc ! addresses ! / +---------inode-------------+ ! filename ! inode # ! +--------------------+
More than one filename can reference the same inode number; these files aresaid to be 'hard linked' together.
! filename ! inode # ! +--------------------+ \ >--------------> ! permbits, etc ! addresses ! / +---------inode-------------+ ! othername ! inode # ! +---------------------+
On the other hand, there's a special file type whose data part carriesa path to another file. Since it is a special file, the OS recognizes thedata as a path, and redirects opens, reads, and writes so that, instead ofaccessing the data within the special file, they access the data in thefile named by the data in the special file. This special file iscalled a 'soft link' or a 'symbolic link' (aka a 'symlink').
! filename ! inode # ! +--------------------+ \ .-------> ! permbits, etc ! addresses ! +---------inode-------------+ / / / .----------------------------------------------' ( '--> !"/path/to/some/other/file"! +---------data-------------+ / } .~ ~ ~ ~ ~ ~ ~ }-- (redirected at open() time) ( } '~~> ! filename ! inode # ! +--------------------+ \ '------------> ! permbits, etc ! addresses ! +---------inode-------------+ / / .----------------------------------------------------' ( '-> ! data ! ! data ! etc. +------+ +------+
Now, the filename part of the file is stored in a special file of its ownalong with the filename parts of other files; this special file is called adirectory. The directory, as a file, is just an array of filename parts ofother files.
When a directory is built, it is initially populated with the filename partsof two special files: the '.' and '..' files. The filename part for the '.'file is populated with the inode# of the directory file in which the entryhas been made; '.' is a hardlink to the file that implements the currentdirectory.
The filename part for the '..' file is populated with the inode# of thedirectory file that contains the filename part of the current directoryfile. '..' is a hardlink to the file that implements the immediate parentof the current directory.
The 'ln' command knows how to build hardlinks and softlinks; the'mkdir' command knows how to build directories (the OS takes care of theabove hardlinks).
There are restrictions on what can be hardlinked (both links must reside onthe same filesystem, the source file must exist, etc.) that are notapplicable to softlinks (source and target can be on seperate file systems,source does not have to exist, etc.). OTOH, softlinks have otherrestrictions not shared by hardlinks (additional I/O necessary to completefile access, additional storage taken up by softlink file's data, etc.)
In other words, there's tradeoffs with each.
Now, let's demonstrate some of this...
ln in action
Let's start off with an empty directory, and create a file in it
~/directory $ ls -lia total 3 73477 drwxr-xr-x 2 lpitcher users 1024 Mar 11 20:16 . 91804 drwxr-xr-x 29 lpitcher users 2048 Mar 11 20:16 .. ~/directory $ echo "This is a file" >basic.file ~/directory $ ls -lia total 4 73477 drwxr-xr-x 2 lpitcher users 1024 Mar 11 20:17 . 91804 drwxr-xr-x 29 lpitcher users 2048 Mar 11 20:16 .. 73478 -rw-r--r-- 1 lpitcher users 15 Mar 11 20:17 basic.file ~/directory $ cat basic.file This is a fileNow, let's make a hardlink to the file
~/directory $ ln basic.file hardlink.file ~/directory $ ls -lia total 5 73477 drwxr-xr-x 2 lpitcher users 1024 Mar 11 20:20 . 91804 drwxr-xr-x 29 lpitcher users 2048 Mar 11 20:18 .. 73478 -rw-r--r-- 2 lpitcher users 15 Mar 11 20:17 basic.file 73478 -rw-r--r-- 2 lpitcher users 15 Mar 11 20:17 hardlink.file ~/directory $ cat hardlink.file This is a file
We see that:
- hardlink.file shares the same inode (73478) as basic.file
- hardlink.file shares the same data as basic.file
If we change the permissions on basic.file:
~/directory $ chmod a+w basic.file ~/directory $ ls -lia total 5 73477 drwxr-xr-x 2 lpitcher users 1024 Mar 11 20:20 . 91804 drwxr-xr-x 29 lpitcher users 2048 Mar 11 20:18 .. 73478 -rw-rw-rw- 2 lpitcher users 15 Mar 11 20:17 basic.file 73478 -rw-rw-rw- 2 lpitcher users 15 Mar 11 20:17 hardlink.file
then the same permissions change on hardlink.file.
The two files (basic.file and hardlink.file) share the same inode and data,but have different file names.
Let's now make a softlink to the original file:
~/directory $ ln -s basic.file softlink.file ~/directory $ ls -lia total 5 73477 drwxr-xr-x 2 lpitcher users 1024 Mar 11 20:24 . 91804 drwxr-xr-x 29 lpitcher users 2048 Mar 11 20:18 .. 73478 -rw-rw-rw- 2 lpitcher users 15 Mar 11 20:17 basic.file 73478 -rw-rw-rw- 2 lpitcher users 15 Mar 11 20:17 hardlink.file 73479 lrwxrwxrwx 1 lpitcher users 10 Mar 11 20:24 softlink.file -> basic.file ~/directory $ cat softlink.file This is a file
Here, we see that although softlink.file accesses the same data asbasic.file and hardlink.file, it does not share the same inode (73479 vs73478), nor does it exhibit the same file permissions. It does show a newpermission bit: the 'l' (softlink) bit.
If we delete basic.file:
~/directory $ rm basic.file ~/directory $ ls -lia total 4 73477 drwxr-xr-x 2 lpitcher users 1024 Mar 11 20:27 . 91804 drwxr-xr-x 29 lpitcher users 2048 Mar 11 20:18 .. 73478 -rw-rw-rw- 1 lpitcher users 15 Mar 11 20:17 hardlink.file 73479 lrwxrwxrwx 1 lpitcher users 10 Mar 11 20:24 softlink.file -> basic.file
then we lose the ability to access the linked data through the softlink:
~/directory $ cat softlink.file cat: softlink.file: No such file or directory
However, we still have access to the original data through the hardlink:
~/directory $ cat hardlink.file This is a file
You will notice that when we deleted the original file, the hardlink didn'tvanish. Similarly, if we had deleted the softlink, the original file wouldn'thave vanished.
A further note with respect to hardlink files
When deleting files, the data part isn't disposed of until all the filenameparts have been deleted. There's a count in the inode that indicates howmany filenames point to this file, and that count is decremented by 1 eachtime one of those filenames is deleted. When the count makes it to zero,the inode and its associated data are deleted.
By the way, the count also reflects how many times the file has been openedwithout being closed (in other words, how many references to the file arestill active). This has some ramifications which aren't obvious at first:you can delete a file so that no "filename" part points to the inode,without releasing the space for the data part of the file, because the fileis still open.
Have you ever found yourself in this position: you notice that/var/log/messages (or some other syslog-owned file) has grown too big, andyou
rm /var/log/messages touch /var/log/messages
to reclaim the space, but the used space doesn't reappear? This is because,although you've deleted the filename part, there's a process that's got thedata part open still (syslogd), and the OS won't release the space for thedata until the process closes it. In order to complete your spacereclamation, you have to
kill -SIGHUP `cat /var/run/syslogd.pid`
to get syslogd to close and reopen the file.
You can use this to your advantage in programs: have you ever wondered howyou could hide a temporary file? Well, you could do the following:
{ FILE *fp; fp = fopen("some.hidden.file","w"); unlink("some.hidden.file"); /* deletes the filename part */ /* some.hidden.file no longer has a filename and is truely hidden */ fprintf(fp,"This data won't be found\n"); /* access the data part */ /*etc*/ fclose(fp); /* finally release the data part */ }
=============================================================================
Softlinks, also called symlinks, are the easiest to understand, especially because you’ve probably already used them. A softlink fills the same role as a Windows shortcut. Simply put, a softlink is a file that points to another file. When you create a softlink, you are creating a new file that exists only as a pointer to a file elsewhere on the system.
All links are created with the ln
command, using the -s
flag if you want a softlink (if you don’t use -s
, you’ll get a hardlink, which I’ll talk about in a second). The syntax of the command is:
For example, the following command will create a softlink to /usr/bin/firefox called firefox (in my “Desktop” directory):
You can see the softlink’s target by using the ls -l
command. You can also use this command to detect broken softlinks:
Now that we understand softlinks, let’s talk about hardlinks.
Whereas a softlink is a new file that points to an already-existing file, a hardlink is another instance of the original file. A diagram is the easiest way to explain what that means:
You can click on either of the images for a larger version. What it explains is that, when you create a hardlink, you are creating another pointer to the data location on disk, not a pointer to the existing file. That means that editing a hard link of a file is equivalent to editing the original instance of the file.
To drive the point home: a softlink is a shortcut to an existing file, whereas a hardlink is a reference to a location on disk (or, more accurately, a location in the filesystem). This means that the concept of a shortcut, a link pointing to another file, doesn’t make sense for hardlinks. But, what does make sense is asking how many references exist to a given location on disk (how many hardlinks exist for a file), which you can see by running the ‘stat’ command:
So for example, in this screenshot I’ve created a file and then built three hardlinks to it. When I run the ‘stat’ command on any of the files, it will show that there is a reference count of 4:
There are two major limitations of hardlinks. In these cases, you must use a softlink:
- A link across filesystems
Because a hardlink is a direct reference to the underlying filesystem, you can’t hardlink across filesystems.
- Linking to a directory
You can’t use a hardlink to link to a directory.
In the cases listed above, you must use a softlink because a hardlink simply won’t work. There are also cases where softlinks are preferable to hardlinks, even though either will work. For example, you’d probably want to pick a softlink when you want to create a shortcut especially when the destination of that shortcut might change in the future. For example, if you have a launcher to a beta version of an application, you may wish to use a softlink so you can easily change the target of the link between versions.
In most of the remaining cases (creating a link to a file on the same filesystem), hardlinks can be preferable for the following major reasons:
- Performance
There is a slight performance boost to be gained from using hardlinks. This is because since a hardlink references a spot on disk, rather than referencing another another file (which then references the actual spot on disk you want), there is one less disk seek involved in hardlinking.
- Storage space
Hardlinks don’t take up any additional space, since they are simply a reference to an already existing space of disk. Creating a softlink is creating a new file, and will consume a small amount (usually 4KB) of space on your filesystem.
Additionally, hardlinks are preferable because a softlink is vulnerable to losing the ‘master’ instance of a file (the file to which all the softlinks point). If the original file is deleted, then all softlinks to it become invalid. With a hardlink, you can delete any of the instances, including the original, and as long as at least one instance exists the file will remain on the system.
其他参考:http://www.cyberciti.biz/tips/understanding-unixlinux-symbolic-soft-and-hard-links.html
http://www.ugrad.cs.ubc.ca/~cs219/CourseNotes/Unix/commands-links.html