fswatch reports files/directories that are being read (Linux/Ubuntu/inotify_monitor)

[denilsonsa]

How to reproduce:

1. Run fswatch . in one terminal (or `fswatch -m inotify_monitor).
2. Open another terminal.
3. Execute one of: ls the_directory_where_you_are or cat some_file_inside_the_directory

Results (output of -x option):

/home/foo/bar IsDir
/home/foo/bar PlatformSpecific

Expected results: Only modified files/directories should be changed. Reading a directory or a file should not have any impact.

[mfornasa]

Seeing the same issue. Possible fix?

[denilsonsa]

Quick and dirty workaround: use the following shell script wrapper.

#!/bin/sh
/full/path/to/fswatch -x "$@" | sed '
    s/ IsDir//
    s/ PlatformSpecific//
    /^[^ ]*$/d
    s/ [a-zA-Z]\+$//
'

This wrapper will not work if your files contain space characters.

[bombazook]

This issue also breaks fswatch -1 -m inotify_monitor behaviour

[denilsonsa]

Slightly better wrapper script:

#!/bin/sh
/full/path/to/fswatch -x "$@" | sed '
    s/ IsDir//
    s/ PlatformSpecific//
    s/\( [A-Z][a-zA-Z]\+\)\+$/ XXX_KEEP_THIS_LINE_XXX/
    / XXX_KEEP_THIS_LINE_XXX$/!d
    s/ XXX_KEEP_THIS_LINE_XXX$//
'

I highly recommend to use fswatch with 'poll monitor' on LINUX systems
fswatch -r -m poll_monitor /your/path
=> fast and reliable recursive scanning, takes not a lot of CPU (~5% , 4 cores, i5-2450M), but less than 10MB ram. I am scanning ~32.000 files in ~2800 sub-directories. It reacts on changes/updates in 0.1second.

Hope, it helps someone.

[sgbotsford]

FS watch is a general file system watcher. Given the nature of the events that the underlying system call does, reading a directory is an event.. fswatch has some capability for event filtering. Using it with -n (numeric flags) allows you to bitwise OR it to the flags of interest.

[ahmgithubahm]

Slightly better wrapper script:

#!/bin/sh
/full/path/to/fswatch -x "$@" | sed '
    s/ IsDir//
    s/ PlatformSpecific//
    s/\( [A-Z][a-zA-Z]\+\)\+$/ XXX_KEEP_THIS_LINE_XXX/
    / XXX_KEEP_THIS_LINE_XXX$/!d
    s/ XXX_KEEP_THIS_LINE_XXX$//
'

Would love a little explanation of what the last three lines are there to achieve ?

[denilsonsa]

@ahmgithubahm It's been a couple of years, but I think I still remember why. The output could be something like this:

path/foo/bar IsDir
path/foo/bac PlatformSpecific
path/foo/baz PlatformSpecific SomeOtherReason
path/foo/bay SomeOtherReason

For each path, there could be multiple reasons why it was listed. (I don't remember if this was the case; I assume so, otherwise why would I write those extra lines? Please correct me if I'm wrong!)

The naive script would filter the third line, but the improved version would keep it.

I stopped using fswatch (and the wrapper script) shortly after writing that workaround, so I can't provide any further help.

[ahmgithubahm]

@denilsonsa thanks. Did you use any other tool instead?

[denilsonsa]

@ahmgithubahm For my purpose, lsyncd was a nice alternative. Took me some time to properly write a configuration file, but it worked fine.

[sswam]

You had one job fswatch... uninstalled, I'll use inotifywait.

[emcrisostomo]

This is by design: fswatch dumps whatever events its backend raises. Perhaps filtering could be improved, but what's described in this issue is expected behaviour. Actually, @sgbotsford has described how I'm using it when I need to filter events.

Furthermore, I'm adding a feature to 'bubble' events received in the same batch, and this will alleviate cases in which some backends generate multiple events for the same path with different flags.