多次错误地通知新文件

Question

Using inotify to monitor a directory for any new file created in the directory by adding a watch on the directory by

    fd = inotify_init();
    wd = inotify_add_watch(fd, "filename_with_path", IN_CLOSE_WRITE);
    inotify_add_watch(fd, directory_name, IN_CLOSE_WRITE);

    const int event_size = sizeof(struct inotify_event);
    const int buf_len = 1024 * (event_size + FILENAME_MAX);
    while(true) {
        char buf[buf_len];
        int no_of_events, count = 0;
        no_of_events = read(fd, buf, buf_len);
        while(count < no_of_events) {
            struct inotify_event *event = (struct inotify_event *) &buf[count];
            if (event->len) {
                if (event->mask & IN_CLOSE_WRITE) {
                    if (!(event->mask & IN_ISDIR)) {
                         //It's here multiple times 
                    }
                }
            }
            count += event_size + event->len;
        }

When I scp a file to the directory, this loops infinitely. What is the problem with this code ? It shows the same event name and event mask too. So , it shows that the event for the same, infinite times.

There are no break statements . If I find an event, I just print it and carry on waiting for another event on read(), which should be a blocking call. Instead, it starts looping infinitely. This means, read doesn't block it but returns the same value for one file infinitely.

This entire operation runs on a separate boost::thread.

EDIT: Sorry all. The error I was getting was not because of the inotify but because of sqlite which was tricky to detect at first. I think I jumped the gun here. With further investigation, I did find that the inotify works perfectly well. But the error actually came from the sqlite command : ATTACH

That command was not a ready-only command as it was supposed to. It was writing some meta data to the file. So inotify gets notification again and again. Since they were happening so fast, it screwed up the application.I finally had to breakup the code to understand why.

Thanks everyone.

Answer 1

I don't see anything wrong with your code...I'm running basically the same thing and it's working fine. I'm wondering if there's a problem with the test, or some part of the code that's omitted. If you don't mind, let's see if we can remove any ambiguity.

Can you try this out (I know it's almost the same thing, but just humor me) and let me know the results of the exact test?

1) Put the following code into test.c

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
#include <sys/inotify.h>

int main (int argc, char *argv[])
{
   char target[FILENAME_MAX];
   int result;
   int fd;
   int wd;   /* watch descriptor */
   const int event_size = sizeof(struct inotify_event);
   const int buf_len = 1024 * (event_size + FILENAME_MAX);

   strcpy (target, ".");

   fd = inotify_init();
   if (fd < 0) {
      printf ("Error: %s\n", strerror(errno));
      return 1;
   }

   wd = inotify_add_watch (fd, target, IN_CLOSE_WRITE);
   if (wd < 0) {
      printf ("Error: %s\n", strerror(errno));
      return 1;
   }

   while (1) {
     char buff[buf_len];
     int no_of_events, count = 0;

     no_of_events = read (fd, buff, buf_len);

     while (count < no_of_events) {
       struct inotify_event *event = (struct inotify_event *)&buff[count];

       if (event->len){
         if (event->mask & IN_CLOSE_WRITE)
           if(!(event->mask & IN_ISDIR)){
              printf("%s opened for writing was closed\n", target);
              fflush(stdout);
           }
       }
       count += event_size + event->len;
     }
   }

   return 0;
}

2) Compile it with gcc:

gcc test.c

3) kick it off in one window:

./a.out

4) in a second window from the same directory try this:

echo "hi" > blah.txt

Let me know if that works correctly to show output every time the file is written to and does not loop as your code does. If so, there's something important your omiting from your code. If not, then there's some difference in the systems.

Sorry for putting this in the "answer" section, but too much for a comment.

Answer 2

我的猜测是read返回-1，并且由于您从未尝试修复错误，因此在下一次调用read时又遇到了另一个错误，该错误也返回-1。