Hello All. I desperately need help. I moved a perfectly working project from an old Win 10 laptop (Pro) to a new Win 10 laptop (Home). It's code is simple enough, it registers a path watcher on a directory (nothing special, something like c:\folder, to which I have opened all permissions). See the following code: Path path = Paths.get(dirDTO.getPath()); path.register(watcher, new WatchEvent.Kind<?>[]{ ExtendedWatchEventKind.ENTRY_RENAME_FROM, ExtendedWatchEventKind.ENTRY_RENAME_TO, StandardWatchEventKind.ENTRY_CREATE,...
This and issue #5 are the same thing - the iterator is fail-fast and in both implementations when the underlying collection being iterated changes via the call the cancelImpl() on FileNotFound you get the ConcurrentModificationException (granted it's a rubbish name when in a single thread!) Simplest one liner change is to make the 'keys' HashMap a ConcurrentHashMap. Alterntively remove the 'keys.remove()' from cancelImpl() and make it the callers responsibility.. (uff!) Our junit test is built upon...
We've been testing and it turns out that it does indeed work with APFS. Out of the box though we encountered a problem which turns out to be the ConcurrentModificaitonException is issue 6. It's very easy to fix, I'll comment over there..
Hi, Has anyone used jpatchwatch on APFS, introduced in High Sierra? Our testing idicated BarbaryWatchService doesn't behave as expected, so we'll need to try jpathwatch but perhaps someone has tried this already? Thanks, Justin
Hi, Has anyone used jpatchwatch on APFS, introduced in High Sierra? Our testing idicated BarbaryWatchService doesn't behave as expecte, so we'll need to try jpathwatch but perhaps someone has tried this already? Thanks, Justin
As you can see there's not much going on with jpathwatch any more. As expected, JDK7...
Don't suppose this will be fixed? I run into the same problem on OSX and monitoring...