Ubuntu w/ all updates, JDK 6u21, 44dca4908ecb, fs.inotify.max_user_watches=99999 in /etc/sysctl.conf, fresh user dir. Start IDE, switch to Favorites tab, expand ~/Desktop (normally empty). Start GNOME Terminal, cd Desktop, touch hello. Nothing appears in the IDE, even after returning focus to it. Source > Scan for external changes does work. No apparent warnings in IDE log nor in /var/log/messages. The same test works fine with Nautilus, so native file notifications are indeed working on my system generally.
Well, the infrastructure is only bound to the folders covered by the addRecursiveListener (based on Yarda's advice).
I have expected that it would have the same coverage as the original refresh-after-window-activated, but it seems it behaves differently.
The notifications, for sure, work for source folders of opened projects (and java infrastructure does pick them up and update its metadata). Thus lowering to P2.
I generally agree that it should work for any folder hierarchy (and any editor opened) in the IDE.
For Windows this shall be easy to fix. Get a notifications about a file being changed, look if there is FileObject for it in memory. If so, call refresh. If not look if there is a parent. If yes, do refresh.
However for other systems (that don't listen on all filesystem changes) we need a way to add/remove native listeners as soon as FileObjects are created/garbage collected. That will need some special API between masterfs and the watchers.
Applies also to FileBuiltQuery. For example, edit a class in a GUI app, then Run. Switch back to the IDE - still displayed as out of date, until you close the app so the process finishes and an old-style refresh is triggered. Before native listeners were introduced, the out-of-date badge would disappear from the editor soon after switching back to the IDE.
Adjusting summary to emphasize that this applies also to files inside projects but not in the source roots, e.g. target/classes.
*** Bug 191133 has been marked as a duplicate of this bug. ***
*** Bug 191348 has been marked as a duplicate of this bug. ***
*** Bug 191843 has been marked as a duplicate of this bug. ***
*** Bug 191211 has been marked as a duplicate of this bug. ***
Disgustingly pragmatic solution: core- main#a4a49524a55f
Integrated into 'main-golden', will be available in build *201011270001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
Log: #190462: Keeping the automatic fs refresh when focus gained on, just skipping all files that are under control of recursive listeners (e.g. the majority)
Looks fine to me. v. Build 101129-e5fa9d201a2b
Good, marking verified then.
This fix is not very satisfactory. It reintroduces the dreaded "scanning for external changes" process, even when we _have_ the ability to use native listeners. Would much prefer that the native listeners be used whenever code asks to listen to changes on a disk file or folder.
Overall we have improved the system over the state in 6.9. It works and is more efficient.
Agreed that the state is preferable to that in 6.9, but I would not consider us to have "implemented native file notifications" when they are implemented for only a subset of the files the IDE is listening to!
can someone clarify what is needed to be done on client side to be native-listened?
because by default c++ project source roots are not listened as well.
They are listened only if register them in indexing api
(In reply to comment #17)
> can someone clarify what is needed to be done on client side to be
Native listening is enabled for all subtrees under FileObject which's addRecursiveListener method is called.
great, thanks!(In reply to comment #18)
> (In reply to comment #17)
> > can someone clarify what is needed to be done on client side to be
> > native-listened?
> Native listening is enabled for all subtrees under FileObject which's
> addRecursiveListener method is called.