我有一个小型应用程序,它监视目录树中特定类型的文件名(*.monitored)。它统计匹配文件的数量,使用 inotify 监视添加或删除匹配文件的各种事件,并可以轮询报告当前文件数量,以及过去几年添加和删除文件的平均速率秒。目录树可以包含数十万个文件,因此我试图避免维护受监视文件的列表。
如果我运行:
touch foo.monitored
我得到 IN_CREATE,并设置 num_files=1
touch foo.ignored
我得到 IN_CREATE,忽略它,并保留 num_files=1
mv foo.ignored foo.monitored
生成:
IN_MOVED_FROM 为 foo.ignored 我忽略了它,所以 num_files=1
IN_MOVED_TO 为 foo.monitored,我将其作为新文件,因此设置 num_files=2,但是旧的 foo.monitored 已被覆盖,所以我的总数是错误的。
我找不到表明旧 foo.monitored 消亡的事件 - 有没有办法在不维护巨大的文件名结构的情况下做我想做的事情?
Thanks!
不,inotify 不会在这里帮助你。在这种情况下,它不会发出删除事件。
也许一种折衷的解决方案是记录每个目录中有多少个受监视的文件,然后每次收到不明确的信号时重新扫描该目录?
然而,使用 inotify 来监视目录树有更大的问题。您是否考虑过如果将包含数千个受监视文件的目录移入或移出树会发生什么情况?即使在树中移动目录也是有问题的。
编辑:其他想法:
分别在每个文件上添加 inotify 监视。这或许不是一个好的计划。
计数器只有在您读取时才准确;任何读取计数然后期望与读取的内容相匹配的调用者都会有一个令人讨厌的竞争条件错误等待发生。因此,接受计数器可能有点错误,并在有机会时纠正它可能是可以的。
每 5 个移动事件后进行一次全面扫描。
移动事件发生后,等待 30 秒查看是否还有更多事件,然后才进行扫描。
将树分成几个部分(“桶”),并记录每个部分的计数。这应该会减少扫描开销。
记录每个受监控文件路径的哈希值。与记录实际文件名相比,这可能会减少内存/麻烦。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)