linux inotify 监控子目录,linux监控文件系统：inotify

inotify events

IN_ACCESS +

文件被访问 read, execve

IN_ATTRIB *

元数据该表，例如权限，timestamp，链接数，user/group ID等等。

IN_CLOSE_WRITE +

可写文件被关闭

IN_CLOSE_NOWRITE *

非可写的文件或者目录被关闭

IN_CREATE +

文件或者目录在监控目录中被创建(也就是说这个事件只可能在

监控目录时才可能产生)

IN_DELETE +

文件或目录在监控目录中被删除(同上)

IN_DELETE_SELF

监控的目录/文件本身被删除(如果一个对象被移动到其他文件系统，

此事件也会被触发)，此外一个IN_IGNORED事件随后会产生在对应的watch descriptor上。这样我们就可以知道具体哪个监控的对象被删除了。

IN_MODIFY +

文件被修改 write, truncate

IN_MOVE_SELF

关注的文件/目录本身被move了。(目前不清楚具体事件指的是什么)

IN_MOVED_FROM +

当文件被rename时，产生在包含老文件名称的目录上。

IN_MOVED_TO +

当文件被rename时，产生在包含新文件名称的目录上。

例如官方的例子:

rename("dir1/myfile", "dir2/myfile");

对dir1产生IN_MOVED_FROM事件，对dir2产生IN_MOVED_TO事件，

对对myfile产生IN_MOVE_SELF事件。

inotify_event结构中的cookie字段在这里有用处，FROM和TO这连个事件的cookie值被设置为相同，为了将一次mv操作产生的多个事件关联到一起。

IN_OPEN *

文件或目录被打开。

IN_MOVE = IN_MOVED_FROM | IN_MOVED_TO.

IN_CLOSE = IN_CLOSE_WRITE | IN_CLOSE_NOWRITE

NOTE由于event queue可能产生溢出，因此事件可能溢出。故可靠性要求高的程序需要周期性的进行一致性校核和重构。

inotify可以和io复用机制一起使用(select poll epoll).

事件可能有合并操作产生，故不能用inotify精确记录事件发生数目。

rename操作保证事件的顺序(因为事件是由ordered queue存储)。

可以在目录/proc/[pid]/fdinfo目录下查看watch descriptors的详细信息。

Limitations and caveats

细节略，可直接查看原文。

BUGS文档中提到了一个关于watch descriptor重用的bug，当文件被删除或者文件系统被unmount，或者调用inotify_rm_watch取消监控，未读事件中对应的watch descriptor仍然是可读的，如果这个时候内核将watch descriptor分配给新的监控对象，就可能出现一个watch descriptor对应着两个对象，一个是删除监控但未读事件中存在，一个是新分配的监控对象，造成逻辑错误。文档中说这个错误出现的概率很低，目前没有收到相关的报告，故3.15版之前还没有处理这个可能的bug。

个人建议：可以将新增监控对象这个操作缓存起来，在每次read到没有数据时，确保当前event queue中不可能有过时的watch descriptor时，再进行监控操作分配新的wd，避免这个bug描述的情况产生。