OsxFileEventFunctions

java.lang.Object
- net.rubygrapefruit.platform.internal.jni.AbstractFileEventFunctions
- - net.rubygrapefruit.platform.internal.jni.OsxFileEventFunctions

All Implemented Interfaces:: NativeIntegration

public class OsxFileEventFunctions
extends AbstractFileEventFunctions

Nested Class Summary
- Nested classes/interfaces inherited from class net.rubygrapefruit.platform.internal.jni.AbstractFileEventFunctions
  AbstractFileEventFunctions.AbstractFileWatcher, AbstractFileEventFunctions.NativeFileWatcherCallback, AbstractFileEventFunctions.WatcherFactory

Constructor Summary

Constructors
Constructor Description

OsxFileEventFunctions()

Method Summary

All Methods Instance Methods Concrete Methods
Modifier and Type	Method	Description
`FileWatcher`	`startWatching(java.util.Collection<java.lang.String> paths, long time, java.util.concurrent.TimeUnit unit, FileWatcherCallback callback)`	Start watching the given directory hierarchies.

Methods inherited from class net.rubygrapefruit.platform.internal.jni.AbstractFileEventFunctions
createWatcher

Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

- Constructor Detail
  - OsxFileEventFunctions
```
public OsxFileEventFunctions()
```
- Method Detail
  - startWatching
```
public FileWatcher startWatching(java.util.Collection<java.lang.String> paths,
                                 long time,
                                 java.util.concurrent.TimeUnit unit,
                                 FileWatcherCallback callback)
```
    Start watching the given directory hierarchies.
    Remarks:
    
    Changes to any descendants to the given paths are reported.
    
    Changes to the given paths themselves are not reported.
    
    Changes are reported as canonical paths. This means:
    
    When watching a path with a different case, the canonical one is used to report changes.
    
    Symlinks are resolved and changes are reported against the resolved path.
    
    Events arrive from a single background thread unique to the FileWatcher.
    
    Removals are reported as a single REMOVED event.
    
    Renames are reported as the source file being REMOVED and the target being CREATED.
    
    Exceptions happening in the callback are currently silently ignored.