不可行。inotify仅监听文件系统事件（如IN_CREATE、IN_MOVED_TO），无法感知inode复用、硬链接增减或rename导致的inode变更；唯一可落地的方式是定期stat()比对st_ino与st_ctime。

Linux下用inotify监控目录inode变化可行吗

不可行。inotify 本身不提供 inode 变更通知，它只监听文件系统事件（如 IN_CREATE、IN_MOVED_TO、IN_ATTRIB），而 IN_ATTRIB 虽然可能由 chown/chmod 触发，但 不会因硬链接增减或 rename 导致的 inode 复用而触发——因为这些操作不修改目标 inode 的属性字段（st_atime/st_mtime/st_ctime 可能变，但 inotify 对 st_ctime 变化无可靠响应）。

• inotify 无法感知同一目录下两个路径是否突然指向同一个 inode（例如 ln a b 后 a 和 b 共享 inode）
• rename("x", "y") 不会触发源路径的 inotify 事件（除非你同时 watch x 所在目录并捕获 IN_MOVED_FROM，但这反映的是路径变动，不是 inode 状态）

真正能感知inode变更的只有stat()轮询+缓存对比

唯一可落地的方式是定期调用 stat() 获取目录的 st_ino 和 st_ctime，与上次结果比对。注意：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 目录的 st_ino 在绝大多数情况下是稳定的（ext4/xfs/btrfs 均保证目录 inode 不变），但 格式化、restore、rsync --delete + recreate 目录等操作会导致 inode 重分配
• 更可靠的信号其实是 st_ctime（change time）：只要目录被 mkdir/rmdir/rename/ln/chmod/chown，它就一定会更新；但注意 NFS 或某些挂载选项（如 noatime）可能影响 ctime 刷新精度
• 不要依赖 st_mtime：目录的 mtime 仅在创建/删除直接子项时更新，不包括子目录内变更

struct stat sb;
if (stat("/path/to/dir", &sb) == 0) {
    if (sb.st_ino != last_ino || sb.st_ctime != last_ctime) {
        // inode 或元数据已变，需重新扫描
    }
}

为什么不用fanotify或dnotify

• dnotify 已废弃，不支持目录递归，且同样不报告 inode 变更，只提供路径级事件
• fanotify 主要用于文件访问控制（access decision），虽能监听 FAN_MODIFY 等，但：
  • 它监控的是“打开/写入”行为，不是元数据变更
  • 无法获取目标路径的当前 st_ino，必须自己再 stat() 一次
  • 配置复杂（需 O_RDONLY | O_LARGEFILE open + fanotify_mark()），且普通用户通常无权限

实际工程中要注意的三个细节

• 即使目录 st_ino 不变，其父目录的 st_ctime 也会在 rename 进来时更新——所以若监控的是动态挂载点或符号链接目标，应同时检查父目录的 ctime
• 使用 stat() 时务必检查返回值和 errno，NFS 超时或权限不足会导致 stat() 失败，此时不能默认 inode 未变
• 高频轮询（如 <100ms）会显著增加 syscalls 开销；建议结合 inotify 监控目录内容变更（IN_CREATE | IN_MOVED_TO | IN_DELETE），仅在收到事件后才调用 stat() 做二次确认

inode 变更不是常规文件系统事件，没有内核级通知机制。所有“实时”方案最终都绕不开主动 stat + 缓存比对，区别只在于触发时机是否足够聪明。