官方介绍：https://man7.org/linux/man-pa...inotifyeventsIN_ACCESS+fileisaccessedread,execveIN_ATTRIB*表的元数据，如权限，时间戳，编号链接、用户/组ID等。IN_CLOSE_WRITE+可写文件关闭IN_CLOSE_NOWRITE*不可写文件或目录关闭IN_CREATE+监控目录下创建文件或目录（即只有监控目录时才可能产生该事件）IN_DELETE+文件或目录已删除被监控的目录（同上）IN_DELETE_SELF被监控的目录/文件本身被删除（如果一个对象被移动到另一个文件系统，也会触发这个事件），随后会在相应的监视描述符上产生一个IN_IGNORED事件。这样我们就可以知道具体的监控对象被删除了。IN_MODIFY+文件被修改写入相关的文件/目录，truncateIN_MOVE_SELF本身已被移动。（不清楚具体事件指的是什么）IN_MOVED_FROM+文件重命名时，在包含旧文件名的目录上生成。IN_MOVED_TO+重命名文件时，在包含新文件名的目录中生成。比如官方的例子：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_NOWRITENOTE由于事件队列可能会溢出，所以事件可能会溢出。因此，对可靠性要求高的程序需要定期进行一致性检查和重构。inotify可以和io多路复用机制（selectpollepoll）一起使用。合并操作可能会产生事件，所以不能使用inotify来准确记录事件数。重命名操作保证了事件的顺序（因为事件是由有序队列存储的）。您可以在目录/proc/[pid]/fdinfo中查看监视描述符的详细信息。Limitations和caveats的细节省略，可以直接查看原文。BUGS文档提到了有关监视描述符重用的错误。当删除文件或卸载文件系统，或调用inotify_rm_watch取消监听时，未读事件中对应的watch描述符仍然可读。如果此时内核将watchdescriptor分配给一个新的监控对象，watchdescriptor可能对应两个对象，一个是删除监控但存在于未读事件中，另一个是新分配的监控对象，导致逻辑错误。文档上说这个错误的概率很低，目前还没有收到相关报告，所以这个可能的bug在3.15版本之前没有处理。个人建议：可以缓存添加监控对象的操作。每次都没有读取到数据时，确保当前事件队列中没有过时的watch描述符，然后进行监听操作分配新的wds，就可以避免这个bug描述。情况出现。
