This repository represents the version of fsnotify that is used as part of Joyent's Fork of Prometheus.
This fork adds FEN support to allow fsnotify to function on illumos.
This repository is downstream of fsnotify.
To better understand and maintain our differences from fsnotify, we try to manage branches and tags in a specific fashion. First and foremost, all branches and tags from the upstream fsnotify repository are mirrored here.
Anything that is Joyent-specific begins with a joyent/ prefix.
Branches with Joyent modifications are named joyent/<version>, such as
joyent/1.4.7. This is a branch that starts from the fsnotify
v1.4.7 tag. These branches will have all of our patches
rebased on top of them. Currently, this repository is consumed by
prometheus, which contains a go vendor directory for this repository. The
vendored version will be based on a tag in this repository that uses the form
joyent/v<version>j<branch release num>. The first release as described
above would be: joyent/v1.4.7j1. If we need to cut another release
from this branch, we would tag it joyent/v1.4.7j2 and continue to
increment the number after the j. Note we use the j instead of r
which would more traditionally be used to indicate a revision. We use
j in case fsnotify for some reason wants to use r in its version strings.
When it comes time to update to a newer version of fsnotify, we would take the following steps:
- Ensure that we have pushed all changes from
fsnotify/fsnotifyand synced all of our branches and tags. - Identify the release tag that corresponds to the point release. For
this example, we'll say that's
v1.4.8. - Create a new branch named
joyent/<version>from the tag. In this case we would name the branchjoyent/1.4.8. - Rebase all of our patches on to that new branch, removing any patches that are no longer necessary.
- Test the new version of fsnotify.
- Review and Commit all relevant changes.
- Create a new tag
joyent/v1.4.8j1. - Update our fork of prometheus to point to the new tag.
fsnotify utilizes golang.org/x/sys rather than syscall from the standard library. Ensure you have the latest version installed by running:
go get -u golang.org/x/sys/...Cross platform: Windows, Linux, BSD and macOS.
| Adapter | OS | Status |
|---|---|---|
| inotify | Linux 2.6.27 or later, Android* | Supported  |
| kqueue | BSD, macOS, iOS* | Supported |
| ReadDirectoryChangesW | Windows | Supported |
| FSEvents | macOS | Planned |
| FEN | Solaris 11 | In Progress |
| fanotify | Linux 2.6.37+ | |
| USN Journals | Windows | Maybe |
| Polling | All | Maybe |
* Android and iOS are untested.
Please see the documentation and consult the FAQ for usage information.
fsnotify is a fork of howeyc/fsnotify with a new API as of v1.0. The API is based on this design document.
All releases are tagged based on Semantic Versioning. Further API changes are planned, and will be tagged with a new major revision number.
Go 1.6 supports dependencies located in the vendor/ folder. Unless you are creating a library, it is recommended that you copy fsnotify into vendor/github.com/fsnotify/fsnotify within your project, and likewise for golang.org/x/sys.
Please refer to CONTRIBUTING before opening an issue or pull request.
See example_test.go.
When a file is moved to another directory is it still being watched?
No (it shouldn't be, unless you are watching where it was moved to).
When I watch a directory, are all subdirectories watched as well?
No, you must add watches for any directory you want to watch (a recursive watcher is on the roadmap #18).
Do I have to watch the Error and Event channels in a separate goroutine?
As of now, yes. Looking into making this single-thread friendly (see howeyc #7)
Why am I receiving multiple events for the same file on OS X?
Spotlight indexing on OS X can result in multiple events (see howeyc #62). A temporary workaround is to add your folder(s) to the Spotlight Privacy settings until we have a native FSEvents implementation (see #11).
How many files can be watched at once?
There are OS-specific limits as to how many watches can be created:
- Linux: /proc/sys/fs/inotify/max_user_watches contains the limit, reaching this limit results in a "no space left on device" error.
- BSD / OSX: sysctl variables "kern.maxfiles" and "kern.maxfilesperproc", reaching these limits results in a "too many open files" error.