linux监控文件系统：inotify

官方介绍：https://man7.org/linux/man-pa...

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

1. 由于event queue可能产生溢出，因此事件可能溢出。故可靠性要求高的程序需要周期性的进行一致性校核和重构。
2. inotify可以和io复用机制一起使用（select poll epoll）.
3. 事件可能有合并操作产生，故不能用inotify精确记录事件发生数目。
4. rename操作保证事件的顺序（因为事件是由ordered queue存储）。
5. 可以在目录/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描述的情况产生。