在 linux 底下的鏈結檔有兩種，一種是類似 windows 的快捷方式功能的檔案，可以讓你快速的鏈結到目標檔案(或目錄)，這種是軟鏈結； 另一種則是透過檔案系統的 inode 鏈結來產生新檔名，而不是產生新檔案！這種稱為硬鏈結 (hard link)。 這兩種玩意兒是完全不一樣的東西呢！現在就分別來談談。
在目錄下建立乙個條目，記錄著檔名與 inode 編號，這個 inode 就是原始檔的 inode。
刪除任意乙個條目，檔案還是存在，只要引用數量不為 0。
# ln /etc/crontab .
# ll -i /etc/crontab crontab
34474855 -rw-r--r--. 2 root root 451 jun 10 2014 crontab
34474855 -rw-r--r--. 2 root root 451 jun 10 2014 /etc/crontab
當原始檔被刪除了，鏈結檔案就打不開了。
因為記錄的是路徑，所以可以為目錄建立符號鏈結。
# ll -i /etc/crontab /root/crontab2
34474855 -rw-r--r--. 2 root root 451 jun 10 2014 /etc/crontab
53745909 lrwxrwxrwx. 1 root root 12 jun 23 22:31 /root/crontab2 -> /etc/crontab
每個檔案都會占用乙個 inode ，檔案內容由 inode 的記錄來指向；
想要讀取該檔案，必須要經過目錄記錄的檔名來指向到正確的 inode 號碼才能讀取。
也就是說，其實檔名只與目錄有關，但是檔案內容則與 inode 有關。那麼想一想， 有沒有可能有多個檔名對應到同乙個 inode 號碼呢？有的！那就是 hard link 的由來。 所以簡單的說：hard link 只是在某個目錄下新增一筆檔名鏈結到某 inode 號碼的關連記錄而已。
舉個例子來說，假設我系統有個 /root/crontab 他是 /etc/crontab 的實體鏈結，也就是說這兩個檔名鏈結到同乙個 inode ， 自然這兩個檔名的所有相關資訊都會一模一樣(除了檔名之外)。實際的情況可以如下所示：
[root@www ~]# ln /etc/crontab . <==建立實體鏈結的命令
[root@www ~]# ll -i /etc/crontab /root/crontab
1912701 -rw-r--r-- 2 root root 255 jan 6 2007 /etc/crontab
1912701 -rw-r--r-- 2 root root 255 jan 6 2007 /root/crontab
實體鏈結的檔案讀取示意圖
上圖的意思是，你可以透過 1 或 2 的目錄之 inode 指定的 block 找到兩個不同的檔名，而不管使用哪個檔名均可以指到 real 那個 inode 去讀取到最終資料！那這樣有什麼好處呢？最大的好處就是『安全』！如同上圖中， 如果你將任何乙個『檔名』刪除，其實 inode 與 block 都還是存在的！ 此時你可以透過另乙個『檔名』來讀取到正確的檔案資料喔！此外，不論你使用哪個『檔名』來編輯， 最終的結果都會寫入到相同的 inode 與 block 中，因此均能進行資料的修改哩！
一般來說，使用 hard link 配置鏈結檔案時，磁碟的空間與 inode 的數目都不會改變！ 我們還是由圖 來看，由圖中可以知道， hard link 只是在某個目錄下的 block 多寫入乙個關連資料而已，既不會新增 inode 也不會耗用 block 數量哩！
備註:hard link 的製作中，其實還是可能會改變系統的 block 的，那就是當你新增這筆資料卻剛好將目錄的 block 填滿時，就可能會新加乙個 block 來記錄檔名關連性，而導致磁碟空間的變化！不過，一般 hard link 所用掉的關連資料量很小，所以通常不會改變 inode 與磁碟空間的大小喔！
由上圖其實我們也能夠知道，事實上 hard link 應該僅能在單一檔案系統中進行的，應該是不能夠跨檔案系統才對！ 因為上圖就是在同乙個 filesystem 上嘛！所以 hard link 是有限制的：
不能跨 filesystem；
不能 link 目錄。
不能跨 filesystem 還好理解，那不能 hard link 到目錄又是怎麼回事呢？這是因為如果使用 hard link 鏈結到目錄時， 鏈結的資料需要連同被鏈結目錄底下的所有資料都建立鏈結，舉例來說，如果你要將 /etc 使用實體鏈結建立乙個 /etc_hd 的目錄時，那麼在 /etc_hd 底下的所有檔名同時都與 /etc 底下的檔名要建立 hard link 的，而不是僅鏈結到 /etc_hd 與 /etc 而已。 並且，未來如果需要在 /etc_hd 底下建立新檔案時，連帶的， /etc 底下的資料又得要建立一次 hard link ，因此造成環境相當大的複雜度。 所以囉，目前 hard link 對於目錄暫時還是不支援的啊！
相對於 hard link ， symbolic link 可就好理解多了，基本上， symbolic link 就是在建立乙個獨立的檔案，而這個檔案會讓資料的讀取指向他 link 的那個檔案的檔名！由於只是利用檔案來做為指向的動作， 所以，當**檔被刪除之後，symbolic link 的檔案會『開不了』， 會一直說『無法開啟某檔案！』。實際上就是找不到原始『檔名』而已啦！
[root@www ~]# ln -s /etc/crontab crontab2
[root@www ~]# ll -i /etc/crontab /root/crontab2
1912701 -rw-r--r-- 2 root root 255 jan 6 2007 /etc/crontab
654687 lrwxrwxrwx 1 root root 12 oct 22 13:58 /root/crontab2 -> /etc/crontab
關於上述的說明，我們以如下圖示來解釋：
符號鏈結的檔案讀取示意圖
由 1 號 inode 讀取到鏈結檔的內容僅有檔名，根據檔名鏈結到正確的目錄去取得目標檔案的 inode ， 最終就能夠讀取到正確的資料了。你可以發現的是，如果目標檔案(/etc/crontab)被刪除了，那麼整個環節就會無法繼續進行下去， 所以就會發生無法透過鏈結檔讀取的問題了！
這裡還是得特別留意，這個 symbolic link 與 windows 的快捷方式可以給他划上等號，由 symbolic link 所建立的檔案為乙個獨立的新的檔案，所以會占用掉 inode 與 block 喔！
由上面的說明來看，似乎 hard link 比較安全，因為即使某乙個目錄下的關連資料被殺掉了， 也沒有關係，只要有任何乙個目錄下存在著關連資料，那麼該檔案就不會不見！舉上面的例子來說，我的 /etc/crontab 與 /root/crontab 指向同乙個檔案，如果我刪除了 /etc/crontab 這個檔案，該刪除的動作其實只是將 /etc 目錄下關於 crontab 的關連資料拿掉而已， crontab 所在的 inode 與 block 其實都沒有被變動！
linux中硬鏈結與符號鏈結（軟鏈結）的關係
首先要弄清楚,在linux系統中,核心為每乙個新建立的檔案分配乙個inode 索引結點 每個檔案都有乙個惟一的inode號。檔案屬性儲存在索引結點裡，在訪問檔案時，索引結點被複製到內存在，從而實現檔案的快速訪問。一 硬鏈結 硬鏈結說白了是乙個指標，指向檔案索引節點，系統並不為它重新分配inode。可...
Linux的硬鏈結與軟鏈結（符號鏈結）
linux的檔案鏈結方式分為硬鏈結與軟鏈結 也叫符號鏈結 兩種，在linux中鏈結也被視為檔案來看待，一樣可以被執行 編輯和訪問。對系統中的應用程式而言，對鏈結的操作就是對原始檔案的操作，所以鏈結不是副本。如果熟悉linux的檔案系統與目錄樹 相關部落格鏈結擴充套件檔案系統 檔案系統與目錄樹的關係 ...
硬鏈結與符號鏈結
索引節點 inode 要 了解鏈結，我們首先得了解乙個概念，叫索引節點 inode 在linux系統中，核心為每乙個新建立的檔案分配乙個inode 索引結點 每個檔案 都有乙個惟一的inode號，我們可以將inode簡單理解成乙個指標，它永遠指向本檔案的具體儲存位置。檔案屬性儲存在索引結點裡，在訪問...