Having the following scenerio:
The recursive listener is attached to gen-classes folder which has 2 files created in it.
The clean deletes the build folder.
Only single file event is delivered (randomly for either org/netbeans/api/java/project/Bundle.java or org/netbeans/modules/java/project/ui/Bundle.java).
The native listener OSXWatcher correctly delivered event about change in build:
FINE [org.netbeans.modules.masterfs.watcher.OSXNotifier]: Event on /Users/tom/Projects/netbeans/test/java.project/build/classes-generated/org/netbeans/modules/java/project/ 0
FINE [org.netbeans.modules.masterfs.watcher.OSXNotifier]: Event on /Users/tom/Projects/netbeans/test/java.project/build/classes-generated/org/netbeans/spi/java/project/support/ui/ 0
Also the following change was delivered:
FINE [org.netbeans.modules.masterfs.watcher.OSXNotifier]: Event on /Users/tom/Projects/netbeans/test/java.project/ 0
I've looked into doc and according to it it may happen that only the /Users/tom/Projects/netbeans/test/java.project/ can be delivered for delete.
As far as I can tell, the API asked you to listen on some/folder/path via addWatch method, so it is reasonable to expect that if there was some change, you will deliver change for some/folder/path and not for some/ or some/folder/, right?
If you are able to detect this case, then you can deliver ALL_CHANGE. If you are unable to detect this kind of event collapsing, then I guess we are out of luck.
Anyway the fix needs to be done primarily in OSXNotifier, which is your creation, so passing back to you, Tomáši.
I can do it in OSXNotifier. Originally I did it but Nejedlak remove the filtering due to performance reasons. As far as I remember the reason was that FS does the same in more efficient way.