消费端读取的文件被删除重建，如何无跨进程通信检测处理？

这个方案在绝大多数常规场景下是可运行的，但无法做到100%的绝对可靠，核心逻辑的合理性和失效边界如下：

方案成立的核心依据 #

你的思路本质是利用POSIX系统的两个基础规则：

• 当你通过FD打开文件之后，这个打开的FD和对应的文件实体是强绑定的：哪怕文件从路径上被删除（unlink），只要FD没有关闭，这个文件的inode就不会被内核回收，你用fstat()拿到的旧文件inode值会一直保持稳定，不会发生变化。
• 路径只是一个指向inode的硬链接，当路径上的文件被删除重建、被其他文件覆盖替换时，路径对应的inode号必然发生变化——这时候把路径上stat()拿到的inode值和FD对应的旧inode值做对比，就能识别出“路径指向的文件已经不是之前打开的那个”的场景。

方案的典型失效场景 #

单靠inode号做对比，会在以下场景出现误判：

• inode号复用冲突：如果旧文件被删除后对应的inode被内核快速回收，新创建的文件恰好被分配了完全相同的inode号，此时对比结果会一致，但实际上两个文件是完全独立的实体。这种情况在本地小文件系统上出现概率极低，但在tmpfs、NFS/SMB等网络文件系统上出现概率会明显升高。
• 跨挂载点的inode冲突：如果目标路径下被临时挂载了其他文件系统，不同挂载点的文件系统之间没有全局的inode唯一约束，可能出现新文件的inode号和旧文件的inode号完全相同的情况。
• 硬链接残留场景：如果旧文件被删除前，在其他路径下存在指向它的硬链接，旧文件的inode不会被回收，此时新创建的文件也可能被分配到相同的inode号，造成误判。

不需要在消费端和生产端之间加任何自定义通信逻辑，只要在原有思路上做小幅优化，就能覆盖绝大多数生产环境场景：

• 不要只对比inode号，要把fstat()获取的完整文件唯一标识存储下来：即同时对比st_ino（inode号）和st_dev（文件所属的设备ID）。这两个值的组合在单台主机上是全局唯一的，可以完全规避跨文件系统、跨挂载点的inode号冲突问题。
• 对齐stat()的返回异常处理逻辑：
  • 当对目标路径调用stat()返回-1、且errno为ENOENT时，说明文件目前处于“被删除、尚未重建”的状态，保留旧FD等待下一次检测周期即可，不需要做额外操作。
  • 当stat()返回成功时，将拿到的st_dev+st_ino和存储的旧值做对比，只要任意一个值不匹配，就说明路径指向的文件已经被替换，此时直接关闭旧FD，重新通过路径打开新文件，存储新文件的标识信息即可。
• 轮询检测的开销控制：stat()是极低开销的系统调用，按1-5秒的周期做一次轮询，对系统性能的影响可以忽略不计。

效率更优的替代实现 #

如果觉得固定周期轮询的空转开销太高，可以直接利用Linux内核提供的inotify接口实现文件变更感知，全程不需要跨进程通信：

• 仅需要对目标文件所在的父目录注册inotify监听，关注IN_DELETE_SELF（目标文件被删除）、IN_MOVED_TO（有新文件被移动到目标路径）、IN_MOVED_FROM（目标文件被移走）三类事件。
• 当内核推送文件变更事件时，再通过stat()对比文件标识、重新打开新文件即可。这种方式没有轮询的空转开销，事件触发的延迟通常在毫秒级，比固定周期轮询的响应速度快很多。

• 注意对齐软链接的处理逻辑：如果目标路径是软链接，要保证fstat()和路径stat()的软链接追踪逻辑一致——要么都跟随软链接拿到最终实体文件的属性，要么都获取软链接本身的属性，不要混用追踪和非追踪的接口，否则会出现对比逻辑失效。
• 不要依赖文件大小、读取位置的变化判断文件是否被替换：旧FD对应的文件表项和路径的文件变更完全解耦，如果读取位置一直停在旧文件的EOF位置，哪怕文件被替换，消费端也不会收到任何读报错，这也是原程序无法感知文件重建的核心原因。

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