官网介绍：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
因为event queue可能产生溢出，因而事件可能溢出。故可靠性要求高的程序须要周期性的进行一致性校核和重构。
bugs：文档中提到了一个对于watch descriptor重用的bug，当文件被删除或者文件系统被unmount，或者调用inotify_rm_watch勾销监控，未读事件中对应的watch descriptor依然是可读的，如果这个时候内核将watch descriptor调配给新的监控对象，就可能呈现一个watch descriptor对应着两个对象，一个是删除监控但未读事件中存在，一个是新调配的监控对象，造成逻辑谬误。
文档中说这个谬误呈现的概率很低，目前没有收到相干的报告，故3.15版之前还没有解决这个可能的bug。
集体倡议：能够将新增监控对象这个操作缓存起来，在每次read到没有数据时，确保以后event queue中不可能有过期的watch descriptor时，再进行监控操作调配新的wd，防止这个bug形容的状况产生。