※ 引述《HILL33LOVE (就是愛希爾)》之銘言：
: 最近看軟連結跟硬連結的比較，有整理一下筆記資訊，對於硬連結的觀念是都使用同一個
: inode，省硬碟空間等等，但是對於”實務”上還是不是很了解大家平常都使用在那邊？
: 再請大家給點指教，謝謝
我自己在實務上做過的, 是讓同一個可執行檔具有多種"操作模式".
這也是系統上常看見的"實務應用". 例如用以下指令列出 /bin/
下面 link count 大於 1 的所有檔案:
$ find /bin/ -type f -links +1 -exec stat -c "%h %i %n" '{}' \; | sort
2 7340502 /bin/gunzip
2 7340502 /bin/uncompress
(...)
3 7340137 /bin/bunzip2
3 7340137 /bin/bzcat
3 7340137 /bin/bzip2
以 bunzip2 為例好了, 如果我要它解壓縮並送到 stdout 的話, 會做:
$ bunzip2 -c 某檔.bz2
但是, 如果以 bzcat 叫它的話, 它會直接進入 "-c" 的操作模式:
$ zcat 某檔.bz2
兩者結果是一樣的. 寫程式用過一陣子, 後來不知怎樣就不這麼玩了...
順便提一下 hard link 的基本觀念, 有問題請大家幫我訂正
所謂"檔案", 是個資料結構, 它唯一的 id 是 inode number,
而非檔名, 因為同一個"檔案"可以有很多檔名, 而且沒有先後之分!
所以, 想像中, "檔案", 比較是 inode, 而不是 "檔名".
如上, inode 7340137 指向一個可執行檔, 並具有三個平起平坐的檔名:
/bin/bunzip2, /bin/bzcat, /bin/bzip2 (這三個名子完全"等價"!)
hard link 的另一個用途是, 例如, 讓它用 /bin/bzip2 跟 /usr/bin/bzip2
都找得到. 但是我的 Debian 上的 /bin/ 現在是 /usr/bin/ 的 symbolic link...
另外, hard link 引申出一個 admin 必須小心的觀念, 例如
$ rm <一個檔案>
其實並不"消滅"<一個檔案>, 而是 unlink(2) <一個檔案>!
那個名字被 unlinked 的"檔案" 其實還在
只要它的 link-count 非 0 或被 opened
而有個 file descriptor.
rm(1) 所消滅的是名字, 不是檔案
假設 admin 發現 /bin/sh "不乖", 於是找了新的版本,
他 # rm /bin/sh, # cp <新版> /bin/ 然後以為做完了.
那就麻煩了.... 因為舊的可能還存在:
1. 它還有 hard links
2. 它還被 opened (在 /proc/<pid>/fd/ 下找得到)
要徹底"消滅"這個 inode, 必須消滅以上兩點, 它才官方不存在