内核 4.x 中的 dnotify 是不是已过时？

Posted 2023-02-17

【中文标题】内核 4.x 中的 dnotify 是不是已过时？

【英文标题】：Is dnotify obsolete in kernel 4.x?内核 4.x 中的 dnotify 是否已过时？

【发布时间】：2019-02-08 06:53:46

【问题描述】：

我正在阅读fcntl manual page 并遇到了dnotify：

文件和目录更改通知（dnotify）

建议新应用程序应该改用inotify，但我认为它们不一样，因为inotify 与char * 路径一起工作，使其遭受文件重命名（或覆盖MOVED_FROM/MOVED_TO事件），但 dnotify 使用不同的文件描述符：

int fcntl(int fd, int cmd, ... /* arg */ );

据我所知，dnotify 不是inotify 的子集，反之亦然。

即使我想通过文件描述符而不是inotify 允许的文件路径订阅事件，是否不鼓励在较新的内核中使用dnotify？

【参考方案1】：

如果你仔细阅读the manual page for inotify_add_watch，那么是的，它需要一个路径但是它返回一个“监视描述符”

对应pathname的文件系统对象（inode）

所以路径只用于定位inode。完成后，您将获得对 inode 的引用，并且可以毫无问题地更改文件名。

【讨论】：

问题是为什么不像stat那样返回ino_t。或者我可以安全地将inotify_add_watch返回的inode转换为ino_t吗？linux.die.net/man/2/stat

@SomeName 该文档没有说明从“监视描述符”到实际 inode 的方法，只是说“监视描述符”是 inode 的唯一描述符。为什么需要ino_t？您需要解决的真正和实际问题是什么？

watch_descriptor 的问题是我们不能用它来打开文件。所以我们不得不再次使用char* path 来介绍比赛。这就是我询问dnotify 的原因，因为它正在对文件描述符引用的已打开文件进行操作。

@SomeName 好吧，inotify 事件似乎包含一个文件名，您可以测试它是否是重命名后的“真实”文件名？