修改例子程序修改 handle_perm，让它 总是不允许文件操作。
清单 11. 不允许文件操作1
2
3
4
5
6
7
8
9
10
11
12
13
14
| int handle_perm(int fan_fd, struct fanotify_event_metadata *metadata)
{
struct fanotify_response response_struct;
int ret;
response_struct.fd = metadata->fd;
response_struct.response = FAN_DENY;// 唯一的修改
ret = write(fan_fd, &response_struct, sizeof(response_struct));
if (ret < 0)
return ret;
return 0;
}
|
编译运行：
窗口 1
窗口 2
1
2
| [lm@localhost ~]$ cat f1
cat: f1: Operation not permitted
|
您也可以在 handle_perm 中加入其他的逻辑，比如打开文件 metadata->fd，读取其中的内容，根据文件内容决定是否允许该操作。这正是 AV 软件所做的。
一个模拟 HSM 的 fanotify 应用程序再将 Eric 的例子程序稍加修改，便可以写一个模拟 HSM 的例子程序。
HSM(Hierarchical Storage Management) 是一种经济而且地利用存储设备的存储管理方式。HSM 对用户是透明的，也就是说用户并不知道这种管理方式的存在。
不同的存储设备有不同的容量和价格，容量大的价格便宜的往往速度慢。HSM 将访问速度快的设备作为缓存，将大量文件保存在速度低，价格便宜的存储介质上。当系统需要在快速设备上访问某文件时，将文件真正的内容从其他存储设备上调出，此后再访问该文件就直接在快速设备上读取。但快速设备容量小，因此长期不读的文件将被再次放回到慢速设备上。类似 cache。但此过程对用户透明，用户只感觉到自己在访问本地文件。
在清单 9 的第四行之后加入如下几行代码：
清单 12. 代码1
2
3
4
5
| read(metadata->fd,buf1,sizeof(buf1));
if(strncmp(buf1,"stub",4)==0)
{
write(metadata->fd,"abcd",4);
}
|
这段代码没有特别需要解释的，如果文件内容是 stub，就把它替换为真正的文件内容。真的 HSM 文件会从其他的存储介质上将真实文件内容读出，再替换现有文件。作为简单例子，这里就简单写入几个单词吧。执行效果如下：
1
| [lm@localhost ~]$ echo “stub” >hsmt
|
运行 HSM
1
2
3
4
5
| [lm@localhost ~]$ ./hsm ~/hsmt
在另外的窗口执行 cat
[lm@localhost ~]$ cat ~/hsmt
abcd
|
结束语Fanotify 已经进入内核，而且已经历了 2，3 年的开发，但似乎还是很初级。
在 /usr/include/linux 下面您依然可以看到 inotify.h。
几乎所有的现有相关应用仍然继续使用 inotify，一些项目甚至宣称他们无法迁移到 fanotify。
这都是现实。
不过我却依然看好 fanotify，因为对新事物要充满耐心。缺点总可以慢慢弥补，而创新是最重要的。相比之前的 notifier，fanotify 提供了访问控制，除了 AV，HSM 之外，这个创新特性还会有那些应用场景？回答这个问题恐怕只需要两点：想象力和缓慢流失的时间。 |
