使用旧版 glibc 在 Linux 中监视文件更改答案

【问题标题】：Monitoring file changes in Linux with older glibc使用旧版 glibc 在 Linux 中监视文件更改
【发布时间】：2013-03-04 06:37:57
【问题描述】：

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

在意识到使用epoll无法监控常规文件后，我发现使用inotify可以完成此任务。但是，我在其他地方读到 inotify 所需的库接口已在 2.4 版中添加到 glibc 中，并且我的机器安装了 2.3.4 版。所以我的内核通过 not glibc 支持 inotify。不幸的是，我无法将 glibc 更新到较新的版本，因为它会破坏项目的某些其他部分。

所以我的问题是：

我还可以使用inotify 来监控常规文件吗？我可以获取更新版本的 glibc 并将其放在本地文件夹中（相对于我的代码），在我的 Makefile 中包含路径并使用与inotify 关联的调用吗？如果是这样，我会遇到什么样的问题？
另一种方法是使用fstat，方法是跟踪struct stat 结构的st_mtime 成员。采取这条路线有什么注意事项吗？

如果我的问题表明对这些概念缺乏理解，请在我刚开始使用它们时多多包涵。

【问题讨论】：

标签： c glibc inotify fstat

【解决方案1】：

对于 2 glibc，请参阅以下帖子： Multiple glibc libraries on a single host

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

【讨论】：

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