inotify_add_watch返回-1且errno=ENOSPC是因内核限制watch总数，默认8192，超限后失败；需检查max_user_watches、避免重复添加、复用wd更新mask。
inotify_add_watch 返回 -1 且 errno=ENOSPC 是什么情况
这是最常遇到的底层卡点：内核对 inotify 实例能监控的 inode 总数有限制，默认通常只有 8192。当反复 inotify_add_watch 同一目录（尤其在递归监控未做去重时），或长期运行的程序不断添加新 watch 而未 inotify_rm_watch，就会触达上限，后续调用直接失败。
实操建议：
- 用
cat /proc/sys/fs/inotify/max_user_watches查当前限制，临时调高可执行sudo sysctl fs.inotify.max_user_watches=524288 - 每次
inotify_add_watch后必须检查返回值，if (wd == -1) { perror("inotify_add_watch"); } - 避免对同一路径重复添加 watch；若需更新事件掩码，直接复用原 wd 并传新
mask参数即可，无需先删后加
read() 从 inotify fd 读到的数据结构怎么解析
read() 返回的是原始字节流，不是结构体数组——它由多个变长 struct inotify_event 拼接而成，每个事件末尾紧跟着文件名（null 结尾），长度由 len 字段决定。手动解析错一位，后续全乱。
关键点：
立即学习“C++免费学习笔记（深入）”；
-
struct inotify_event本身不包含文件名，name是独立的 char 数组，起始地址 = (char*)event + sizeof(struct inotify_event) - 必须按
event->len截取 name，不能直接当 C 字符串用strlen，因为中间可能有 \0（虽然极少见） - 一次
read()可能包含多个事件，需用 while 循环 + 偏移累加解析，不能只取第一个
示例片段：
char buf[4096];
ssize_t len = read(inotify_fd, buf, sizeof(buf));
char *ptr = buf;
while (ptr < buf + len) {
struct inotify_event *ev = (struct inotify_event *)ptr;
if (ev->len > 0) {
printf("file: %.*s\n", ev->len - 1, ev->name); // -1 排除末尾 \0
}
ptr += sizeof(struct inotify_event) + ev->len;
}
IN_MOVED_TO 和 IN_MOVED_FROM 怎么配对识别重命名
Linux 内核对 rename() 的处理是原子发两个事件：先 IN_MOVED_FROM（带 cookie），再 IN_MOVED_TO（带相同 cookie）。但二者不一定连续到达——中间可能夹杂其他事件（如 IN_ATTRIB），也不能假设它们在同一 read() 批次里。
实操要点：
- 必须缓存未配对的
IN_MOVED_FROM事件（仅需存 cookie + old_name），超时未匹配则丢弃（比如 1 秒后） -
IN_MOVED_TO到来时，查 cookie 是否在缓存中；匹配则视为 rename，否则当作新建文件（可能是跨设备 move，此时触发的是 copy+unlink） - 注意：
IN_MOVED_FROM的name是旧路径基名，IN_MOVED_TO的name是新路径基名，完整路径需结合 watch descriptor 对应的目录路径拼接
为什么监控子目录要手动递归 add_watch，且不能依赖 IN_CREATE | IN_ISDIR
IN_CREATE 事件只通知“创建了某子项”，但不会自动为你对那个新子目录建立新的 watch。inotify 没有递归模式，所谓“监控整个树”是应用层责任。
典型错误写法：监听父目录，收到 IN_CREATE | IN_ISDIR 就以为已自动监控该子目录——其实只是告诉你“有个目录诞生了”，你得立刻调用 inotify_add_watch 去盯它，否则其内部变化完全收不到。
注意事项：
- 新子目录的 watch 必须在收到事件后立即添加，延迟可能导致中间事件丢失（尤其高频创建场景）
- 务必检查
inotify_add_watch返回值，子目录可能因权限不足、符号链接循环等失败 - 删除子目录时，对应 wd 自动失效，但内核不发通知；需靠
IN_DELETE_SELF或应用层路径维护机制清理本地 wd 映射表
实际跑通的关键不在 API 调用顺序，而在对事件流的无损捕获与状态一致性维护——尤其是 cookie 配对和递归 watch 的时机控制，这两处出问题，监控就变成概率性生效。
