使用较旧的glibc监控Linux中的文件更改

我需要使用文件描述符监视常规文件上的事件。我正在使用CentOS 4.1和内核版本2.6.18.128的机器上工作

在意识到不能使用

epoll

监视常规文件后，我发现可以使用

inotify

完成此任务。但是，我在别处看到，

inotify

所需的库接口在版本2.4中添加到了glibc，我的机器安装了版本2.3.4。因此，我的内核具有inotify支持，而不是glibc。不幸的是，我无法将glibc更新到新版本，因为它会破坏项目的某些其他部分

因此，我的问题是：

我仍然可以使用

inotify

监视常规文件吗？我是否可以获取一个较新版本的glibc并将其放在本地文件夹（相对于我的代码），在我的Makefile中包含路径并使用与

inotify

关联的调用？如果是，我会遇到什么样的问题

另一种方法是通过跟踪

struct stat

结构的

st_mtime

成员，使用

fstat

。走这条路有什么警告吗

---

如果我的问题显示出对这些概念缺乏理解，请耐心等待，因为我刚刚开始使用它们

有关2个glibc，请参见以下帖子：

---

否则，inotify似乎是直截了当的解决方案。

感谢您的链接！一个澄清，因为我在某一点上仍然感到困惑。我参与的项目的其他部分将使用较旧的glibc，因为我是唯一需要更新版本的人。我可以使用两个不同版本的glib来构建单个项目吗？这不会导致一些问题吗？那么，您是否有任何需要旧glibc的特定功能？您不能针对2个不同的库版本进行链接，这将是编译器的模糊条件。只需添加，您可以有2个不同的链接应用程序，并通过带有GLIBC版本的ifdef宏控制调用。是的，有许多功能需要较旧的GLIBC。我们中的一个人曾经尝试过使用较新的glibc，但它在运行时出现了很多错误，这需要时间来解决。这就是为什么我同时需要两个库。那么fstat是我最好的选择吗？如果你的应用程序是一个独立的应用程序，你可以通过修复头文件和库路径来轻松使用不同的glibc，否则fsstat就是最好的选择。