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

Ability to exclude certain files when using recursive watch #48

Closed
shrutika10 opened this issue Aug 6, 2015 · 4 comments
Closed

Ability to exclude certain files when using recursive watch #48

shrutika10 opened this issue Aug 6, 2015 · 4 comments

Comments

@shrutika10
Copy link

We need to be able to exclude certain files when using recursive watch. Currently i did not find anything. Does it already exist? How do we use it?

@digitalextremist
Copy link

I personally use find and individually watch files that I do want.

@nex3
Copy link
Collaborator

nex3 commented Aug 14, 2015

Unless you're individually calling it file-by-file, inotify watches directories, not files. You'll just need to filter out the events after the fact.

@nex3 nex3 closed this as completed Aug 14, 2015
@wmakley
Copy link

wmakley commented Oct 4, 2018

Just ran into this problem when using docker. I had a volume for postgresql data owned by root in my project, and rb-inotify just crashed. I'm moving it elsewhere as a workaround, but it would be nice to ignore it and not crash. Maybe that is a Linux problem and there is nothing that the library can do.

@alexanderadam
Copy link

alexanderadam commented Feb 18, 2019

Having the same issue right now. So is it somehow possible to ignore certain directories?

It looks like overriding RECURSIVE_BLACKLIST should help. But changing / redefining constants is definitely not a good style. Also it is difficult to configure that if rb-inotify is initialized by another library.

Also the check for the recursive blacklist have to be before the call to Dir.new(path) because permission error would appear otherwise anyway.

Maybe making it configurable with an ENV variable would be a simpler solution?

It would help gems like listen or guard if this could be fixed (1, 2, 3, 4, 5).

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

5 participants