使用fanotify监听文件变更时，已删目录下文件路径异常的解决方法

当你删除根目录下的文件夹时，如果该文件夹内的文件仍被某个进程持有打开的文件句柄，fanotify返回的路径就会带上(deleted)后缀——这是因为文件的目录项（dentry）已经从文件系统中移除，但对应的inode还未被释放（因为有进程在使用），内核为了标识这种状态，会在路径中添加这个标记。

你可以通过以下几种方式解决这个问题：

• 优先处理目录删除事件，提前清理子文件句柄
  在收到目录的DELETE DIR事件时，先遍历该目录下的所有文件，主动检查是否有进程持有这些文件的句柄（可以遍历/proc/*/fd下的符号链接，查找指向对应inode的条目）。如果有，要么通知相关进程关闭句柄，要么在你的监听逻辑里提前标记这些文件为待清理状态，避免后续处理时出现带(deleted)的路径。

• 用inode+挂载点替代路径识别文件
  fanotify事件中可以获取到文件的inode编号和挂载点设备号，你可以用这两个值的组合来唯一标识文件，而不是依赖路径。这样即使路径因为删除操作变成(deleted)状态，你依然能通过inode准确识别目标文件，完全不用处理路径里的特殊标记。
  伪代码示例：

  struct fanotify_event_metadata *metadata;
  // 从事件元数据中提取inode和设备号
  ino_t target_inode = metadata->inode;
  dev_t target_dev = metadata->dev;
  // 用target_inode + target_dev作为文件的唯一标识
  

• 过滤(deleted)路径并验证文件实际状态
  当检测到路径包含(deleted)时，调用stat系统调用检查文件状态：如果stat返回ENOENT，说明文件确实已被完全删除，直接忽略该事件；如果stat成功，说明只是目录项被删，此时可以通过inode信息重新关联文件，但这种方法存在竞态风险，可靠性不如前两种。

内容的提问来源于stack exchange，提问作者xzq