連結檔的介紹 & ln 指令的使用

由 匿名使用者 在 週五, 2012/02/24 - 15:15 發表

 

資料來源:http://linux.vbird.org/linux_basic/0230filesystem.php#ln
僅供個人參考備查

 

什麼是連結檔呢?其實連結檔有點類似 Windows 底下的『捷徑』!也就是很多的連結檔案( link file )其實都指向同一個來源檔案( source file )!不過,在所有的檔案類型當中, 連結檔算是比較難理解的一部份了!因為連結檔還分成 Hard link 與 symbolic link 兩種,這兩種連結檔在架構上是完全不一樣的咚咚,底下就來好好的談一談先!


--------------------------------------------------------------------------------------------------------

什麼是 Block ?  什麼是 inode ?

Block是紀錄「檔案內容資料」的地區

inode則是紀錄「該檔案的屬性、及該檔案放置在哪一個Block之內」的資訊

--------------------------------------------------------------------------------------------------------

Hard Link (硬式連結或實際連結)


檔案的讀取方式為:
先由一層一層的目錄取得檔案相關的關連資料, 
再到對應的 inode 取得檔案的屬性,以及檔案內容資料所在的 Block , 
最後到 Block area 取得檔案的資料。
那麼 hard link 怎麼製作檔案的連結呢?!很簡單, Hard Link 只是在某個目錄下新增一個該檔案的關連資料而已!

舉個例子來說,假設我的 /root/crontab 為一個 hard link 的檔案,他連結到 /etc/crontab 這個檔案,也就是說,其實 /root/crontab 與 /etc/crontab 是同一個檔案,只是有兩個目錄( /etc 與 /root )記錄了 crontab 這個檔案的關連資料罷了!也就是說,我由 /etc 這個目錄所記錄的關連資料可知道 crontab 的 inode 放置在 A 處,而由 /root 這個目錄下的關連資料, crontab 同樣也指到 A 處的 inode !所以囉, crontab 這個檔案的 inode 與 block 都沒有改變, 有的只是有兩個目錄記錄了關連資料。

那這樣有什麼好處呢?最大的好處就是『安全!』如同上面提到的 /root/crontab 與 /etc/crontab 中, 不管哪一個檔案被刪除了,其實僅是移除一筆目錄底下的檔案關連性資料,並沒有更動到原本檔案的 inode 與 block 資料呢!而且,不論由那個目錄連結到正確的 crontab 的 inode 與 block , 都可以正確無誤的進行資料的修改喔! ^_^

一般來說,使用 hard link 設定連結檔時,磁碟的空間與 inode 的數目都不會改變! 由上面的說明來看,我們可以知道, hard link 只是在某個目錄下的 block 多寫入一個關連資料,所以當然不會用掉 inode 與磁碟空間囉!

由於 hard link 是在同一個 partition 上面進行資料關連的建立,所以 hard link 是有限制的:

 

  • 不能跨 Filesystem;
  • 不能 link 目錄。
  • 不能跨 Filesystem 還好理解,因為 hard link 本來就是在一個 partition 內建立關連性的, 那不能 hard link 到目錄又是怎麼回事呢?這是因為如果使用 hard link 連結到目錄時, 連結的資料被需要連同被連結目錄底下的所有資料都建立連結,舉例來說,如果你要將 /etc 使用硬式連結建立一個 /etc_hd 的目錄時,那麼在 /etc_hd 底下的所有資料同時都與 /etc 底下的資料要建立 hard link 的,而不能僅是連結到 /etc_hd 與 /etc 而已。 並且,未來如果需要在 /etc_hd 底下建立新檔案時,連帶的, /etc 底下的資料又得要建立一次 hard link ,因此造成環境相當大的複雜度。 所以囉,目前 hard link 對於目錄暫時還是不支援的啊!

 

Symbolic Link (符號連結,亦即是捷徑)

 
相對於 hard link , Symbolic link 可就好理解多了,基本上, Symbolic link 就是在建立一個獨立的檔案, 而這個檔案會讓資料的讀取指向他 link 的那個檔案內容!由於只是利用檔案來做為指向的動作, 所以,當來源檔被刪除之後,symbolic link 的檔案會『開不了』, 會一直說『無法開啟某檔案!』。這裡還是得特別留意,這個 Symbolic Link 與 Windows 的捷徑可以給他劃上等號,由 Symbolic link 所建立的檔案為一個獨立的新的檔案,所以會佔用掉 inode 與 block 喔!


由上面的說明來看,似乎 hard link 比較安全,因為即使某一個目錄下的關連資料被殺掉了, 也沒有關係,只要有任何一個目錄下存在著關連資料,那麼該檔案就不會不見!舉上面的例子來說,我的 /etc/crontab 與 /root/crontab 指向同一個檔案,如果我刪除了 /etc/crontab 這個檔案,該刪除的動作其實只是將 /etc 目錄下關於 crontab 的關連資料拿掉而已, crontab 所在的 inode 與 block 其實都沒有被變動喔!

不過,不幸的是,由於 Hard Link 的限制太多了,包括無法做『目錄』的 link , 所以在用途上面是比較受限的!反而是 Symbolic Link 的使用方面較廣喔!好了, 說的天花亂墜,看您也差不多快要昏倒了!沒關係,實作一下就知道怎麼回事了!

要製作連結檔就必須要使用 ln 這個指令呢!

[root@linux ~]# ln [-sf] 來源檔 目標檔
參數:
-s  :如果 ln 不加任何參數就進行連結,那就是hard link,至於 -s 就是symbolic link
-f  :如果 目標檔 存在時,就主動的將目標檔直接移除後再建立!

範例:
範例一:將 /etc/passwd 複製到 /tmp 底下,並且觀察 inode 與 block
[root@linux ~]# cd /tmp
[root@linux tmp]# cp -a /etc/passwd .
[root@linux tmp]# du -sb ; df -i .
26948   . <== 先注意一下,這裡的容量是多少!
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda1            1537088  144016 1393072   10% /
# 利用 du 與 df 來檢查一下目前的參數~那個 du -sb 
# 是計算整個 /tmp 底下有多少 bytes 的容量啦!

範例二:將 /tmp/passwd 製作 hard link 成為 passwd-hd 檔案
[root@linux tmp]# ln passwd passwd-hd
[root@linux tmp]# du -sb ; df -i .
26948   .
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda1            1537088  144016 1393072   10% /
# 仔細看,即使多了一個檔案在 /tmp 底下,整個 inode 與 block 的容量並沒有改變!
[root@linux tmp]# ls -il passwd*
1242760 -rw-r--r--  2 root root 1746 Jun 29 01:03 passwd
1242760 -rw-r--r--  2 root root 1746 Jun 29 01:03 passwd-hd
# 原來是指向同一個 inode 啊!這是個重點啊!另外,那個第二欄的連結數也會增加!

範例三:將 /tmp/passwd 建立一個符號連結
[root@linux tmp]# ln -s passwd passwd-so
[root@linux tmp]# ls -li passwd*
1242760 -rw-r--r--  2 root root 1746 Jun 29 01:03 passwd
1242760 -rw-r--r--  2 root root 1746 Jun 29 01:03 passwd-hd
1242806 lrwxrwxrwx  1 root root    6 Jul 23 20:02 passwd-so -> passwd
# 仔細看喔,這個 passwd-so 指向的 inode number 不同了!這是一個新的檔案~
# 這個檔案的內容是指向 passwd 的,你可以看到這個檔案的大小,是 6bytes ,
# 怎麼來的?因為 passwd 共有六個字元啊!哈哈!沒錯~這個連結檔的內容只是填寫
# 連結的目標檔案檔名而已!所以,你的連結檔檔名 (有時候含路徑) 有多長,檔案就多大!
[root@linux tmp]# du -sb ; df -i .
26954   .
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda1            1537088  144017 1393071   10% /
# 呼呼!整個容量與 inode 使用數都改變囉~確實如此啊!

範例四:刪除原始檔案 passwd ,其他兩個檔案是否能夠開啟?
[root@linux tmp]# rm passwd
[root@linux tmp]# cat passwd-hd
......正常顯示完畢!
[root@linux tmp]# cat passwd-so
cat: passwd-so: No such file or directory
# 怕了吧?!竟然無法正常的開啟這個檔案呢~

 
要注意囉!使用 ln 如果不加任何參數的話,那麼就是 Hard Link 囉!如同上面的情況,增加了 hard link 之後,可以發現使用 ls -l 時,顯示的 link 那一欄屬性增加了!而如果這個時候砍掉 passwd 會發生什麼事情呢?呵呵! passwd-hd 的內容還是會跟原來 passwd 相同,但是 passwd-so 就會找不到該檔案啦!就是這樣!瞭解了嗎?!

而如果 ln 使用 -s 的參數時,就做成差不多是 Windows 底下的『捷徑』的意思( Symbolic Link,較常用! )。當你修改 Linux 下的 link 檔案時,則更動的其實是『原始檔』,呵呵, 所以不論你的這個原始檔被連結到哪裡去,只要你修改了連結檔,呵呵!原始檔就跟著變囉! 以上面為例,由於你使用 -s 的參數建立一個名為 passwd-so 的檔案,則你修改 passwd-so 時,其內容與 passwd 完全相同,並且,當你按下儲存之後,被改變的將是 passwd 這個檔案!

此外,如果你做了底下這樣的連結:
ln -s /bin /root/bin
那麼如果你進入 /root/bin 這個目錄下,『請注意呦!該目錄其實是 /bin 這個目錄,因為你做了連結檔了!』所以,如果你進入 /root/bin 這個剛剛建立的連結目錄, 並且將其中的資料殺掉時,嗯! /bin 裡面的資料就通通不見了!這點請千萬注意!並不是 /root 底下的資料都是 root 的!還需要注意一下該屬性才行!(其實可以透過 pwd -P 去觀察!)

基本上, Symbolic link 的用途比較廣,所以您要特別留意 symbolic link 的用法呢!未來一定還會常常用到的啦!

------------------------------------------------------------------------------------------------------------------------

關於目錄的 link 數量: 
或許您已經發現了,那就是,當我們以 hard link 進行『檔案的連結』時,可以發現,在 ls -l 所顯示的第二欄位會增加一才對,那麼請教,如果建立目錄時,他預設的 link 數量會是多少? 讓我們來想一想,一個『空目錄』裡面至少會存在些什麼?呵呵!就是存在 . 與 .. 這兩個目錄啊! 那麼,當我們建立一個新目錄名稱為 /tmp/testing 時,基本上會有三個東西,那就是: 
/tmp/testing
/tmp/testing/.
/tmp/testing/..
而其中 /tmp/testing 與 /tmp/testing/. 其實是一樣的!都代表該目錄啊~而 /tmp/testing/.. 則代表 /tmp 這個目錄,所以說,當我們建立一個新的目錄時, 『新的目錄的 link 數為 2 ,而上層目錄的 link 數則會增加 1 』 不信的話,我們來作個測試看看:
[root@linux ~]# ls -ld /tmp
drwxrwxrwt  5 root root 4096 Oct 11 05:15 /tmp
[root@linux ~]# mkdir /tmp/testing1
[root@linux ~]# ls -ld /tmp
drwxrwxrwt  6 root root 4096 Oct 11 13:58 /tmp
[root@linux ~]# ls -ld /tmp/testing1
drwxr-xr-x  2 root root 4096 Oct 11 13:58 /tmp/testing1

 
瞧!原本的所謂上層目錄 /tmp 的 link 數量由 5 增加為 6 ,至於新目錄 /tmp/testing 則為 2 ,這樣可以理解目錄的 link 數量的意義了嗎?! ^_^

Read more >>

關於EC ONE ECONE-top-right.png