共计 1236 个字符，预计需要花费 4 分钟才能阅读完成。
官网介绍：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 形容的状况产生。
