emcrisostomo / fswatch

A cross-platform file change monitor with multiple backends: Apple OS X File System Events, *BSD kqueue, Solaris/Illumos File Events Notification, Linux inotify, Microsoft Windows and a stat()-based backend.
https://emcrisostomo.github.io/fswatch/
GNU General Public License v3.0
5.02k stars 327 forks source link

Feature Request: Recursively Watch Directories Only #98

Closed kjp949 closed 8 years ago

kjp949 commented 8 years ago

I'm using fswatch on FreeBSD. One of the caveats of using kqueue is file descriptor needs to be used for every directory and file being watched by fswatch. I am using fswatch to monitor my media directory for new files being added. It would be nice if there was an option to monitor directories only. I don't need every file being monitored for changes. I've never had an issue with running out of file descriptors but I think one day it could happen.

emcrisostomo commented 8 years ago

Hi @kpeterson11,

Would you please clarify what you are suggesting? If you don't use the -r parameter and pass a directory as an argument, then fswatch will watch that directory (non-recursively). Maybe you are suggesting to recursively watch subdirectories only?

I'm a FreeBSD user and it's pretty easy to run out of file descriptors when watching huge file hierarchies. Fortunately, if that's a requirement, raising the number of files descriptors is easy as well.

kjp949 commented 8 years ago

I'm suggesting to recursively watch subdirectories only.

Sorry for the confusion.

emcrisostomo commented 8 years ago

Don't worry, thanks, it seems a nice feature to have, indeed.

emcrisostomo commented 8 years ago

Hi @kpeterson11,

If you are willing to build the feature/recurse-and-watch-directories-only branch, I've implemented this feature and added the -d option.

Please, let me know if you test it.

kjp949 commented 8 years ago

I've been using your ports version before and it compiles fine for me. The recurse-and-watch-directories-only branch does not compile for me.

Assertion failed: (EST != EST_Unevaluated && EST != EST_Uninstantiated), function isNothrow, file /usr/src/lib/clang/libclangcodegen/../../../contrib/llvm/tools/clang/include/clang/AST/Type.h, line 3020.
Stack dump:
0.  Program arguments: /usr/bin/clang++ -cc1 -triple x86_64-unknown-freebsd9.3 -emit-obj -disable-free -main-file-name libfswatch.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -gdwarf-2 -coverage-file /root/fswatch/libfswatch/src/libfswatch/c/.libs/libfswatch.o -resource-dir /usr/bin/../lib/clang/3.4.1 -dependency-file c/.deps/libfswatch.Tpo -sys-header-deps -MP -MT c/libfswatch.lo -D HAVE_CONFIG_H -D LOCALEDIR="/usr/local/share/locale" -D PIC -I . -I ../.. -I /usr/local/include -internal-isystem /usr/include/c++/4.2 -internal-isystem /usr/include/c++/4.2/backward -O2 -Wall -std=gnu++11 -fdeprecated-macro -fdebug-compilation-dir /root/fswatch/libfswatch/src/libfswatch -ferror-limit 19 -fmessage-length 125 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o c/.libs/libfswatch.o -x c++ c/libfswatch.cpp 
1.  c/libfswatch.cpp:215:1: current parser token 'int'
2.  c/libfswatch.cpp:174:12: LLVM IR generation of declaration 'fsw_init_session'
3.  c/libfswatch.cpp:174:12: Generating code for declaration 'fsw_init_session'
clang++: error: unable to execute command: Abort trap: 6
clang++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd9.3
Thread model: posix
clang++: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
emcrisostomo commented 8 years ago

Hi @kpeterson11, we're hitting a clang bug there: I think I hit it on older versions of OS X too. Changing compiler is not straightforward so that don't worry. Thanks for trying.

kjp949 commented 8 years ago

I do have clang 3.6 on my freebsd 9.3 install. Clang 3.6 itself doesn't crash now but I do get other errors. I did try recompiling libc++ with clang 3.6 thinking that was the cause of the errors but it wasn't. Here are the errors I get incase they are of help. I'm assuming this is why you said it's not so straight forward to switch compilers.

Making all in libfswatch
  CXX      c/libfswatch_mem.lo
  CXX      c/cevent.lo
  CXX      c/libfswatch.lo
  CXX      c/libfswatch_log.lo
  CXX      c++/libfswatch_exception.lo
  CXX      c++/event.lo
c++/event.cpp:53:46: error: no matching constructor for initialization of 'const map<string, fsw_event_flag>'
    static const map<string, fsw_event_flag> flag_by_names = {
                                             ^               ~
/usr/include/c++/4.2/bits/stl_map.h:188:9: note: candidate constructor template not viable: requires 2 arguments, but 15 were
      provided
        map(_InputIterator __first, _InputIterator __last)
        ^
/usr/include/c++/4.2/bits/stl_map.h:204:9: note: candidate constructor template not viable: requires at most 4 arguments, but
      15 were provided
        map(_InputIterator __first, _InputIterator __last,
        ^
/usr/include/c++/4.2/bits/stl_map.h:165:7: note: candidate constructor not viable: requires at most 2 arguments, but 15 were
      provided
      map(const _Compare& __comp, const allocator_type& __a = allocator_type())
      ^
/usr/include/c++/4.2/bits/stl_map.h:175:7: note: candidate constructor not viable: requires single argument '__x', but 15
      arguments were provided
      map(const map& __x)
      ^
/usr/include/c++/4.2/bits/stl_map.h:157:7: note: candidate constructor not viable: requires 0 arguments, but 15 were provided
      map()
      ^
c++/event.cpp:83:46: error: no matching constructor for initialization of 'const map<fsw_event_flag, string>'
    static const map<fsw_event_flag, string> names_by_flag = {
                                             ^               ~
/usr/include/c++/4.2/bits/stl_map.h:188:9: note: candidate constructor template not viable: requires 2 arguments, but 15 were
      provided
        map(_InputIterator __first, _InputIterator __last)
        ^
/usr/include/c++/4.2/bits/stl_map.h:204:9: note: candidate constructor template not viable: requires at most 4 arguments, but
      15 were provided
        map(_InputIterator __first, _InputIterator __last,
        ^
/usr/include/c++/4.2/bits/stl_map.h:165:7: note: candidate constructor not viable: requires at most 2 arguments, but 15 were
      provided
      map(const _Compare& __comp, const allocator_type& __a = allocator_type())
      ^
/usr/include/c++/4.2/bits/stl_map.h:175:7: note: candidate constructor not viable: requires single argument '__x', but 15
      arguments were provided
      map(const map& __x)
      ^
/usr/include/c++/4.2/bits/stl_map.h:157:7: note: candidate constructor not viable: requires 0 arguments, but 15 were provided
      map()
      ^
2 errors generated.
*** [c++/event.lo] Error code 1

Stop in /root/fswatch/libfswatch/src/libfswatch.
*** [all-recursive] Error code 1

Stop in /root/fswatch/libfswatch/src.
*** [all-recursive] Error code 1

Stop in /root/fswatch/libfswatch.
*** [all] Error code 1

Stop in /root/fswatch/libfswatch.
*** [all-recursive] Error code 1

Stop in /root/fswatch.
*** [all] Error code 1

Stop in /root/fswatch.
emcrisostomo commented 8 years ago

Hi @kpeterson11,

Sorry for the belated answer. Yep, that's the reason why I said it wasn't easy. You may have a compliant compiler but lack a compliant libc. The error you're receiving is telling you just that.

Ok, you'll have to wait until I update the port, which will happen very soon.