标签: inotify

假设我想对目录中的所有文件调用某个命令，并设置一个监视来对在该目录中创建的所有文件调用该命令。如果我做：

while( ( sdi = readdir( d )) != NULL ) { ... }
closedir( d );
/* Files created here will be missed */
inotify_add_watch( ... );

那么某些文件可能会丢失。如果我inotify_add_watch()在 之前调用readdir()，文件可能会被执行两次（这将需要相当多的基础设施来防止执行两次，而且似乎边缘情况很难处理）。是否有一种简单的方法可以避免记录循环期间处理的所有文件的名称readdir并将它们与结构中返回的名称进行比较inotify_event？我可以最大限度地减少必要的比较量：

while( ( sdi = readdir( d )) != NULL ) { ... }
inotify_add_watch( ... );
while( ( sdi = readdir( d )) != NULL ) { /* record name */ ... }
closedir( d );

通常第二个readdir()循环不会执行任何操作，但这感觉像是一个糟糕的黑客。

我正在尝试使用 inotify 来监视文件是否在无限循环中被修改。我遇到了一些问题：

1）我有一段时间（1），并且读取不起作用，除非我为该时间的每次迭代创建一个新的文件描述符和一个新的监视描述符（我想做的是在无限循环之前打开这些描述符，但如果其他解决方案可以接受，那么我可以使用它）。这是有效的版本：

 while(1){
    int file_descriptor = inotify_init();
    if (file_descriptor < 0) {
        perror("inotify_init");
    }

    int watch_descriptor = inotify_add_watch(file_descriptor, "/home/user/hello.cfg", IN_CLOSE_WRITE);
    ....

2）我尝试使用掩码 IN_MODIFY，但我读到它在 vim 中不能很好地工作，所以我使用 IN_CLOSE_WRITE。问题是，当我用vim修改文件时，事件被读取，但事件的掩码是IN_IGNORED（掩码0x00008000）。当我使用gedit时，有时事件的掩码是IN_IGNORED，有时是IN_CLOSE_WRITE（掩码0x0000008）。我想知道为什么我在修改文件时会收到 IN_IGNORED，以及为什么该事件不是 IN_CLOSE_WRITE。还有其他方法可以监视单个文件的修改吗？IN_CLOSE_WRITE 是正确的掩码吗？

我正在尝试将“ inotify_add_watch”用于进程。我这样做的目的是在进程被终止时收到通知。

我的通知代码是，

wd = inotify_add_watch(ifd, "/proc",IN_ALL_EVENTS);

但即使进程被删除并且目录从 /proc 文件夹中删除，它也不会通知。

我正在尝试使用 corectl 在 CoreOS 上通过 xhyve 上运行的 docker 容器中设置我的构建过程，corectl/Users/[username]通过 NFS自动挂载。我发现诸如fsmonitor和browser-sync 之类的构建工具依赖于fs.watch它们在 linux上使用inotify来监视更改。inotify 不适用于 NFS [1] [2]。其他人已经解决了这个问题，并决定使用 rsync 将更新的文件发送到容器中，这依赖于构建容器之外的工具。我想分发一个自包含的 docker 镜像，它可以正常工作。

有没有替代 inotify 的方法可以在 NFS 上工作？

我正在寻找一种方法来检查 5 个域的文档根目录以进行目录监视。

对于单个文件夹，它的工作方式是这样的

DIRECTORY_TO_WATCH = "/home/serveradmin/"

我有一个文件夹列表，需要为我的服务器递归检查这些文件夹。

我刚开始学习 python 并且有一些 C 语言的实践经验。刚刚开始学习发展。

有没有人可以帮我解决这个问题？我需要对名为 /tmp/folderlist.txt 的文件中提到的 5 个文件夹进行递归 inotify 监视

我可以参考的地方是否有任何类似的代码可用？

我正在尝试设置一个监视脚本和一个 pdf 合并脚本的串联来检查我的扫描仪写入 pdf 的文件夹。第一个脚本的想法是监视文件夹，直到出现两个 pdf 文件，然后调用第二个脚本。现在的问题是 inotifywait 检测到文件何时创建并且按预期调用第二个脚本，但特别是对于较大的 pdf，这会导致失败，因为扫描仪可能仍会写入 pdf。我将 close_write 事件添加到 inotifywait 但我认为这会被忽略，因为 create 事件已经是 true。我添加了睡眠作为解决方法，但这不仅丑陋，而且在超过固定超时的更大文件上也会失败。检查两个文件是否已完全写入的最佳方法是什么？谢谢。

文件夹检查脚本：

#! /bin/bash
n=0
inotifywait -m -e create,close_write $1 | while read line
do
    n=$(find $1 -type f | wc -l);
    echo $n
    if [ "$n" -eq "2" ] ; then 
      echo "found $n files"
      sleep 5
      ./pdfMergeMove.sh $1 cleanup
      n=0
    fi;
done 

我正在尝试在我的 c/c++ 程序中监视文件的创建。我正在尝试使用 inotify 来实现此目的。但是，当我在代码中no such file or directory进行inotify_add_watch()调用时，我收到了。我正在 Ubuntu 16.04 机器上运行我的程序。该机器在 EC2 云中运行。有人可以告诉我收到 的可能原因no such file or directory error吗？

根据inotify_add_watch的手册页，这甚至不是可能的错误代码之一。我已确保我对要监视的文件具有适当的读取权限等。

这是我的测试程序：

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/inotify.h>
#include <limits.h>

#define MAX_EVENTS  1024
#define LEN_NAME    16
#define EVENT_SIZE  (sizeof (struct inotify_event))
#define BUF_LEN     (MAX_EVENTS * (EVENT_SIZE + LEN_NAME))

int
main(int argc, char **argv)
{
  int length, i = 0, wd;
  int fd;
  char buffer[BUF_LEN];

  /* Initialize …

我知道有多个线程讨论NFS安装卷和文件修改监视问题。由于大多数讨论都是旧的，有些是 8 年前的，所以我的目标是编译一些并再次提出它们，以检查你们用来处理这些问题的最新解决方案是什么。

核心问题
Linux 依赖于inotify一个内核子系统，在文件被修改（更改/删除）时生成事件，而这些事件最常被开发人员工具用来监视文件以触发某些任务。核心问题是，当您通过 NFS 协议共享卷/文件夹时，它不会生成事件，因此工具需要使用轮询方法而不是基于事件触发。

轮询方法通常会产生多个问题，例如 CPU 使用率高、文件更改导致任务触发延迟等。

一些观看工具：

• Webpack 观看： https: //webpack.js.org/configuration/watch/
• 守卫： https: //github.com/guard/guard

热门话题

• 使用 NFS 进行 inotify
• 为什么 inotify 事件在 NFS 挂载上不同？
• Ubuntu 上共享文件夹中的文件更新不会触发 inotify
• 触发 VirtualBox 共享文件夹上的文件更改

不错的解决方案尝试

• Vagrant 文件系统通知转发器插件- 已废弃且不可靠
• vagrant-fsnotify - 被放弃且不可靠

我当前的挑战
我们使用 macOS 作为主机，使用 Vagrant（提供者 Virtualbox）和 Alpine Linux 作为来宾，以及用于服务的 Docker 容器（Node、NGINX...）来运行我们的开发环境，除了以下情况之外，所有设置都运行顺利：前端开发人员需要使用 webpack watch 功能来监视文件修改。它适用于轮询，但有 3-10 秒的延迟。

关于如何解决这个问题有任何更新或建议吗？

我正在运行一个小的inotify脚本,用于在文件上设置监视.每次编辑和保存该文件时,脚本都会注意到触发了DELETE_SELF事件.这是正常的,如果是为什么？inotify子系统不应该注意到文件仍然存在吗？

在Linux中,限制进程可以打开的inotify实例的数量受每个用户ID最大数量的限制,在/ proc/sys/fs/inotify/max_user_instances中指定

自然就是限制每个进程,例如文件FD.由于inotify FD受用户ID的限制,因此它更有可能达到许多进程可能以相同用户ID运行的服务器上的限制.但我想这有理由吗？

这是一个编程问题,因为我必须在我的代码中使用inotify,并希望为系统设置正确的限制.