详细原文：
and:
一、介绍：
inotify 是在 2.6.13 中引入的新功能，它为用户态监视文件系统的变化提供了强大的支持。inotify 是一种文件系统的变化通知机制，如文件增加、删除等事件可以立刻让用户态得知，该机制是著名的桌面搜索引擎项目 beagle 引入的，并在 Gamin 等项目中被应用。
inInotify 是为替代 dnotify 而设计的，它克服了 dnotify 的缺陷，提供了更好用的，简洁而强大的文件变化通知机制：
1． Inotify 不需要对被监视的目标打开文件描述符，而且如果被监视目标在可移动介质上，那么在 umount 该介质上的文件系统后，被监视目标对应的 watch 将被自动删除，并且会产生一个 umount 事件。
2． Inotify 既可以监视文件，也可以监视目录。
3． Inotify 使用系统调用而非 SIGIO 来通知文件系统事件。
4． Inotify 使用文件描述符作为接口，因而可以使用通常的文件 I/O 操作select 和 poll 来监视文件系统的变化。
二、Inotify 可以监视的文件系统事件包括：
- IN_ACCESS，即文件被访问
- IN_MODIFY，文件被 write
- IN_ATTRIB，文件属性被修改，如 chmod、chown、touch 等
- IN_CLOSE_WRITE，可写文件被 close
- IN_CLOSE_NOWRITE，不可写文件被 close
- IN_OPEN，文件被 open
- IN_MOVED_FROM，文件被移走,如 mv
- IN_MOVED_TO，文件被移来，如 mv、cp
- IN_CREATE，创建新文件
- IN_DELETE，文件被删除，如 rm
- IN_DELETE_SELF，自删除，即一个可执行文件在执行时删除自己
- IN_MOVE_SELF，自移动，即一个可执行文件在执行时移动自己
- IN_UNMOUNT，宿主文件系统被 umount
- IN_CLOSE，文件被关闭，等同于(IN_CLOSE_WRITE | IN_CLOSE_NOWRITE)
- IN_MOVE，文件被移动，等同于(IN_MOVED_FROM | IN_MOVED_TO)
注：上面所说的文件也包括目录。
三、举例说明
大家往往使用inotify-tool比较熟悉，对于其监控文件系统的一些特性，却很少有人总结，有些人用开源的Inotify脚本程序进行rsync同步，但我希望还是要对文件事件进行过滤，否则会做大量的重复操作和冗余操作，主要原因是，在我们队文件进行编辑操作的时候会产生大量的冗余事件，这些事件有些是临时文件的产生，有些是对监控文件的冗余操作。详细见下面的测试。
1.使用touch语句创建文件：touch test,产生两个事件：
2.使用vi语句创建test文件，vi test，产生事件如下：
如图所示，会产生一些临时文件，他们一swp与swpx进行结尾。其中512事件代表删除文件，可见我们在进行vi的时候，其实背后会有很多额外的操作开销。但具体问什么需要这么繁琐的过程，目前还不清楚。
3.对通过vi打开的文件，进行write操作，在vi命令提示符下执行w，产生如下8个事件
如图所示，这回会产生一些名字叫4913的事件，这个数字貌似是不变的，就是你write其他文件，也会产生4913事件。但如果创建的文件本身名字就叫4913，那么会产生其它数字的临时文件，真是奇怪...
其中64是move_from事件，是将文件mv出当前路径时产生事件，128代表将其他路径文件移入当前路径，移出与移入操作可以通过cookie值，来确定是否是同一文件。可见，当移动操作时候，是将test移动为test~，其实是修改了名字，通过cookie可以看出，它们是对同一文件的操作。
如果对vi打开的文件做退出操作，即执行q命令：
对同一个文件做write and close操作的时候，即在vi命令行下，执行wq，则产生10个事件如下：
可见，如果不对事件进行监控，一个简单的write操作都会产生很多冗余事件。
但也有些事件是唯一的，举例如下：
1.对已经产生的文件，重新进行touch操作，如test已经产生了，再次执行touch test操作时事件如下：
如图，只产生了write_close事件，覆盖了已经touch的文件。
2.从其他路径cp一个文件，到监控路径：
相当于进行了一次写覆盖操作。
3.从其他路径move一个文件到监控路径：
只产生了move_to事件。
4.刚才看到了，如果write名为test文件，产生临时文件4913，如果我write名为4913的文件时候，事件如下：
如果write为5036，时候，会产生数字为其它的临时文件，真的是有意思。
阅读(2202) | 评论(0) | 转发(0) |
