inotify - 初始化:目录创建时的奇怪行为

Question

我有一个inotify /内核问题。我正在使用“inotify” Python项目进行观察，但是，我的问题仍然是固有的关于inotify内核实现的核心。

Python inotify项目处理递归inotify监视。它提供了一个不错的生成器，使您可以遍历事件。它通过识别目录创建事件并在产生事件之前自动添加这些监视来实现递归监视。

我注意到“mkdir -p”调用有些奇怪的行为。尽管我可以快速，增量地创建单个目录并从事件循环中查看它们，但是“mkdir -p”从不为子目录的子目录或在该子目录中创建的文件生成事件。

有人有什么想法吗？

作品:“mkdir aa && mkdir aa / bb && touch aa / bb / filename”:

(_INOTIFY_EVENT(wd=1, mask=1073742080, cookie=0, len=16), ['IN_ISDIR', 'IN_CREATE'], '/tmp/tmpt3MlIQ', u'aa')
(_INOTIFY_EVENT(wd=2, mask=1073742080, cookie=0, len=16), ['IN_ISDIR', 'IN_CREATE'], u'/tmp/tmpt3MlIQ/aa', u'bb')
(_INOTIFY_EVENT(wd=3, mask=256, cookie=0, len=16), ['IN_CREATE'], u'/tmp/tmpt3MlIQ/aa/bb', u'filename')
(_INOTIFY_EVENT(wd=3, mask=32, cookie=0, len=16), ['IN_OPEN'], u'/tmp/tmpt3MlIQ/aa/bb', u'filename')
(_INOTIFY_EVENT(wd=3, mask=4, cookie=0, len=16), ['IN_ATTRIB'], u'/tmp/tmpt3MlIQ/aa/bb', u'filename')
(_INOTIFY_EVENT(wd=3, mask=8, cookie=0, len=16), ['IN_CLOSE_WRITE'], u'/tmp/tmpt3MlIQ/aa/bb', u'filename')

无效:“mkdir -p aa / bb &&触摸aa / bb /文件名”:

(_INOTIFY_EVENT(wd=1, mask=1073742080, cookie=0, len=16), ['IN_ISDIR', 'IN_CREATE'], '/tmp/tmpuTSxYl', u'aa')
(_INOTIFY_EVENT(wd=1, mask=1073741856, cookie=0, len=16), ['IN_ISDIR', 'IN_OPEN'], '/tmp/tmpuTSxYl', u'aa')
(_INOTIFY_EVENT(wd=1, mask=1073741840, cookie=0, len=16), ['IN_ISDIR', 'IN_CLOSE_NOWRITE'], '/tmp/tmpuTSxYl', u'aa')

当然，我做了下一件显而易见的，无脑的事情，并在“mkdir aa && mkdir aa / bb”中添加了“-p”标志，以确保没有任何“-p”特有的异常，但没什么不同。

“mkdir -p”的GNU实现只是在路径中的分隔符之间进行迭代。没魔术 os.makedirs(相同功能)的Python实现也只是分割路径并枚举部分。但是，GNU不起作用，而Python可以。这似乎暗示着一个竞争条件，除了无论我如何操作这些条件，结果都是相同的。我什至开始在我们要读取事件的epoll上使用琐碎/微小的超时(读取:如果原始超时值有任何延迟，则不再是工厂)。内核中的inotify似乎完全丢失了随后在“mkdir -p”中创建的内容。

我确定我只是想念一些东西。

作为参考，GNU实现中涉及的调用:

http://code.metager.de/source/xref/gnu/coreutils/src/mkdir.c

http://code.metager.de/source/xref/gnu/octave/gnulib-hg/lib/mkdir-p.c#85

http://code.metager.de/source/xref/gnu/octave/gnulib-hg/lib/mkancesdirs.c#67

请注意，我们从GNU的“coreutils”开始，并且显然进入GNU Octave，以实现“mkdir -p”。这是OpenGrok提供的唯一参考。我无法解释这一点，而且我不熟悉。

Python的实现:

https://github.com/python/cpython/blob/master/Lib/os.py#L196

我是否忽略了inotify行为的某些细节？

Answer 1

您到了那里很有趣!

不，本地内核inotify库完全执行documentation所说的。 GNU mkdir -p也完全可以。

我注意到“mkdir -p”调用有些奇怪的行为。我可以
快速，增量地创建单个目录并从中查看它们
事件循环“mkdir -p”从不为子目录产生事件
子目录或在该子目录中创建的文件。

您将不得不尝试使用其他inotify实现来断言PyInotify的递归监视的可信度。仅仅是仅是流行的Python实现这一事实并不能赢得我的信任!

假设您尚未弄乱为参考而产生的示例Python输出，我将做出以下声明。我想说，这是PyInotify的实现，有些懈怠，但并不是很擅长。

对于我们的推测，在考虑文件创建之前，让我们分流一下，从创建目录开始。

您是否注意到，即使在第一种情况下，dirt IN_CREATE的aa

(_INOTIFY_EVENT(wd=1, mask=1073742080, cookie=0, len=16), ['IN_ISDIR', 'IN_CREATE'], '/tmp/tmpt3MlIQ', u'aa')

没有对应的 IN_OPEN和 IN_CLOSE_NOWRITE事件，尽管动作只是 mkdir，但由于某些奇怪的原因，第二种情况下似乎存在这些事件。

(_INOTIFY_EVENT(wd=1, mask=1073741856, cookie=0, len=16), ['IN_ISDIR', 'IN_OPEN'], '/tmp/tmpuTSxYl', u'aa')
(_INOTIFY_EVENT(wd=1, mask=1073741840, cookie=0, len=16), ['IN_ISDIR', 'IN_CLOSE_NOWRITE'], '/tmp/tmpuTSxYl', u'aa')

显然有一些可疑之处。绝对不一致。

我还没有看过PyInotify的实现，也不想浪费我的时间。但是，我已经与本机inotify接口(interface)进行了密切合作，以确保其准确性!它从未错过报告单个事件的机会，也就是说，如果它根本没有发生。

现在，让我们继续进行文件创建部分，这似乎是您的主要问题- mkdir -p永远不会为子目录的子目录或在该子目录中创建的文件产生事件。 这并非总是；取决于实现的程度。

我用 a better inotify implementation复制了与您执行的相同的一组操作。是的，只是为了证明我的主张。

注意事件流显然比PyInotify的报告更准确吗？

Reproduction:

case1: mkdir aa && mkdir aa/bb && touch aa/bb/filename

root@six-k:/opt/test# ls -la
total 8
drwxr-xr-x  2 root root 4096 Mar 18 13:55 .
drwxr-xr-x 20 root root 4096 Mar 18 13:53 ..
root@six-k:/opt/test# fluffyctl -w ./
root@six-k:/opt/test# mkdir aa && mkdir aa/bb && touch aa/bb/filename

捕获的事件:

root@six-k:/home/lab/fluffy# fluffy
event:  CREATE, ISDIR, 
path:   /opt/test/aa

event:  ACCESS, ISDIR, 
path:   /opt/test/aa

event:  ACCESS, ISDIR, 
path:   /opt/test/aa

event:  CLOSE_NOWRITE, ISDIR, 
path:   /opt/test/aa

event:  CREATE, ISDIR, 
path:   /opt/test/aa/bb

event:  ACCESS, ISDIR, 
path:   /opt/test/aa/bb

event:  ACCESS, ISDIR, 
path:   /opt/test/aa/bb

event:  CLOSE_NOWRITE, ISDIR, 
path:   /opt/test/aa/bb

event:  CREATE, 
path:   /opt/test/aa/bb/filename

event:  OPEN, 
path:   /opt/test/aa/bb/filename

event:  ATTRIB, 
path:   /opt/test/aa/bb/filename

event:  CLOSE_WRITE, 
path:   /opt/test/aa/bb/filename

情况2: mkdir -p aa/bb && touch aa/bb/filename

root@six-k:/opt/test# cd ../
root@six-k:/opt# mkdir test2
root@six-k:/opt# cd test2/
root@six-k:/opt/test2# fluffyctl -w ./
root@six-k:/opt/test2# mkdir -p aa/bb && touch aa/bb/filename
root@six-k:/opt/test2#

捕获的事件:

root@six-k:/home/lab/fluffy# fluffy
event:  CREATE, ISDIR, 
path:   /opt/test2/aa

event:  ACCESS, ISDIR, 
path:   /opt/test2/aa

event:  ACCESS, ISDIR, 
path:   /opt/test2/aa/bb

event:  ACCESS, ISDIR, 
path:   /opt/test2/aa/bb

event:  CLOSE_NOWRITE, ISDIR, 
path:   /opt/test2/aa/bb

event:  ACCESS, ISDIR, 
path:   /opt/test2/aa

event:  CLOSE_NOWRITE, ISDIR, 
path:   /opt/test2/aa

event:  CREATE, 
path:   /opt/test2/aa/bb/filename

event:  OPEN, 
path:   /opt/test2/aa/bb/filename

event:  ATTRIB, 
path:   /opt/test2/aa/bb/filename

event:  CLOSE_WRITE, 
path:   /opt/test2/aa/bb/filename

到此为止，子目录及其中的文件上的事件。

答案越来越冗长!

但是，在本机inotify库之上构建的递归实现不能保证所有事件。不可行!如果是的话，对于编写inotify的内核家伙来说，本机已经引入了递归表。

陷阱:

请注意，与我的再现片段相比， create事件确实存在差异吗？在第二种情况下，没有报告该子目录( mkdir -p)。 为什么？ 尽管一切很快，但是递归设置还不够快。在捕获到dir create上的第一个 aa事件时， mkdir -p aa/bb也完成了创建dir bb的工作。因此，dir create没有 bb事件。再次提醒一下，这不是本地inotify库的错；这是因为我们还没有在dir aa上设置事件监视程序，我们将如何在其上接收事件？

我希望一切顺利!

等等，如果甚至未捕获到dir bb的create事件，那么 fluffy似乎如何对其进行监视，并在那里报告了dir'bb`上的后续事件？

好，您正在追踪!您猜对了，但不是全部。 fluffy收到dir create的第一个 aa事件。在处理此事件时， mkdir -p完成了工作，因此没有dir bb create事件。对。但是，虽然 fluffy设置在dir aa上监视，但dir bb已经存在。因此，蓬松的将 bb引入了它的监视范围，因为它确实是dir aa的后代。其余的你已经知道了。由于正在监视，因此它将报告后续事件，其中包括文件创建。

如果您(任何阅读此文件的人)打算在PyInotify GitHub项目页面上提出有关此问题的票证/问题，请随时引用此答案或指向 fluffy。如果您需要更多信息，我会很乐意提供。您也可以在蓬松的GH页面上打开问题，以进行一般性讨论/建议/意见。 fluffy可以使用您的帮助来改善它。