※ 引述《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, 必须消灭以上两点, 它才官方不存在