inotifywait --include doesn't fire for files in newly created directories.
(From this Stack Exchange post)
I want to run inotifywait to watch for all CREATEs of .txt files (recursively) under, let's say, the current directory. I run the following:
inotifywait -mr --event create --format '%e %w %f' --include '\.txt$' .
In another shell (from the same directory), I run the following:
touch 1.txt # inotifywait prints "CREATE ./ 1.txt" - all good.
mkdir mydir # inotifywait prints nothing - all good.
cd mydir # inotifywait prints nothing - all good.
touch 1.txt # inotifywait prints nothing - NOT GOOD. I should have seen a "CREATE" message.
So despite me including the -r option (for which man inotifywait clearly states "Newly created subdirectories will also be watched."), my newly created subdirectory is clearly not being watched.
(FWIW, I'm running Debian GNU/Linux 12 (bookworm) and inotify-tools v3.22.6.0-4.)
This may be a dupe of https://github.com/inotify-tools/inotify-tools/issues/199.
Now this weird. Same as before:
inotifywait -mr --event create --format '%e %w %f' --include '\.txt$' .
Again, in another shell (from the same directory):
mkdir newdir ; touch newdir/newfile.txt # prints nothing, see previous comment.
mkdir newdir.txt ; touch newdir.txt/newfile.txt # file creation causes event. Huh?
So it looks as though when recursively watching a directory, both %w and %f are tested and only if they both match the regex, then the event is triggered. A big thanks to Chris Davies for his Stack Exchange comment.
Just found https://github.com/inotify-tools/inotify-tools/issues/224 - this may also be a dupe.
https://github.com/inotify-tools/inotify-tools/issues/168 discusses 2 bugs, one of which is this bug.
I encountered the same problem. As soon as recursion is involved (in my case, I was waiting for new files being created inside a dynamically created folder structure), --include doesn't work. I had to replace it with --exclude directives.
@static-moonlight (and for anyone else!) In case it helps, systemd.path may also be a potential workaround (found here).