Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
denilsonsa opened this issue Sep 15, 2016 · 12 comments

Comments

@denilsonsa
Copy link

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
Copy link

Seeing the same issue. Possible fix?

@denilsonsa
Copy link
Author

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
Copy link

This issue also breaks fswatch -1 -m inotify_monitor behaviour

@denilsonsa
Copy link
Author

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$//
'

@ghost
Copy link

ghost commented Aug 22, 2018

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
Copy link

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
Copy link

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
Copy link
Author

@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
Copy link

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

@denilsonsa
Copy link
Author

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

@sswam
Copy link

sswam commented Mar 18, 2021

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

@emcrisostomo
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants