Cross-platform file system notifications for Go.

Overview

File system notifications for Go

GoDoc Go Report Card

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 Build Status
kqueue BSD, macOS, iOS* Supported Build Status
ReadDirectoryChangesW Windows Supported Build Status
FSEvents macOS Planned
FEN Solaris 11 In Progress
fanotify Linux 2.6.37+ Planned
USN Journals Windows Maybe
Polling All Maybe

* Android and iOS are untested.

Please see the documentation and consult the FAQ for usage information.

API stability

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.

Usage

package main

import (
	"log"

	"github.com/fsnotify/fsnotify"
)

func main() {
	watcher, err := fsnotify.NewWatcher()
	if err != nil {
		log.Fatal(err)
	}
	defer watcher.Close()

	done := make(chan bool)
	go func() {
		for {
			select {
			case event, ok := <-watcher.Events:
				if !ok {
					return
				}
				log.Println("event:", event)
				if event.Op&fsnotify.Write == fsnotify.Write {
					log.Println("modified file:", event.Name)
				}
			case err, ok := <-watcher.Errors:
				if !ok {
					return
				}
				log.Println("error:", err)
			}
		}
	}()

	err = watcher.Add("/tmp/foo")
	if err != nil {
		log.Fatal(err)
	}
	<-done
}

Contributing

Please refer to CONTRIBUTING before opening an issue or pull request.

Example

See example_test.go.

FAQ

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.

Why don't notifications work with NFS filesystems or filesystem in userspace (FUSE)?

fsnotify requires support from underlying OS to work. The current NFS protocol does not provide network level support for file notifications.

Related Projects

Comments
  • Add Solaris FEN using EventPorts from x/sys/unix

    Add Solaris FEN using EventPorts from x/sys/unix

    What does this pull request do?

    This pull request adds fsnotify support for Solaris and illumos via Solaris FEN. It is a cleanup of #263 by @isaacdavis which in turn was heavily based on #196, authored by @gfrey. I have kept both of them in the AUTHORS file and added myself as well.

    The biggest change from that iteration was moving all of the cgo and unsafe code out into x/sys/unix (see 324630). Additionally, in the process of that work, I wrote a wrapper for port_getn(3c) which I have used here to allow a single call to retrieve multiple events.

    Supersedes #263 Fixes #12

    Where should the reviewer start?

    ~~I squashed and rebased #263 and have preserved my development branch. To see how this code compares to that implementation, this URL will render the diff: https://github.com/nshalman/fsnotify/compare/rebased-solaris-fen...nshalman:illumos-fen-safer~~ This isn't really recognizable compared to the original any more. Hopefully fen.go having been stripped of all the cgo is now readable without really requiring event ports / FEN expertise.

    The heart of the cgo bits now live on in x/sys/unix

    How should this be manually tested?

    All of my testing was run on SmartOS, but the underlying event ports code includes tests that successfully ran under CI on a Solaris host. This PR also includes a GitHub action that runs an OmniOS VM to run the tests for CI.

    ~~Unfortunately, I've seen intermittent test failures and I haven't be able to fully identify what is happening with those.~~ I believe I've finally found all the bugs. This code is sensitive to the short sleeps in some of the integration tests, and thus depends on #422. I've been stress testing with echo {1..72} | xargs -n 1 | xargs -t -I {} -P 24 go test -count={} and the VM tests which used to be flaky are now reliable (and are set to run 10 times rather than just once)

    I have also done a cursory test of compiling hugo (v0.92.0) against this branch and running the tests and resulting binary.

    hugo $ go test --count=1 github.com/gohugoio/hugo/watcher/filenotify
    ok      github.com/gohugoio/hugo/watcher/filenotify     2.818s
    

    Running the resulting hugo binary under truss reveals port_getn being called with arguments revealing that it's the call in fsnotify.

    illumos 
    opened by nshalman 64
  • Does not work in powerpc64 or arm64

    Does not work in powerpc64 or arm64

    Hi,

    I package prometheus for Debian. And I am getting build errors in ppc64el, which seem to originate in fsnotify. If I try to run fsnotify's tests there I get all kind of failures, and a hang:

    github.com/go-fsnotify/fsnotify
       dh_auto_test -O--buildsystem=golang
        go test -v github.com/go-fsnotify/fsnotify
    === RUN   TestPollerWithBadFd
    --- PASS: TestPollerWithBadFd (0.00s)
    === RUN   TestPollerWithData
    --- FAIL: TestPollerWithData (0.00s)
        inotify_poller_test.go:85: expected poller to return true
    === RUN   TestPollerWithWakeup
    --- PASS: TestPollerWithWakeup (0.00s)
    === RUN   TestPollerWithClose
    --- FAIL: TestPollerWithClose (0.00s)
        inotify_poller_test.go:119: expected poller to return true
    === RUN   TestPollerWithWakeupAndData
    --- FAIL: TestPollerWithWakeupAndData (0.00s)
        inotify_poller_test.go:140: expected poller to return true
    === RUN   TestPollerConcurrent
    --- FAIL: TestPollerConcurrent (0.05s)
        inotify_poller_test.go:197: expected true
    === RUN   TestInotifyCloseRightAway
    --- PASS: TestInotifyCloseRightAway (0.05s)
    === RUN   TestInotifyCloseSlightlyLater
    --- PASS: TestInotifyCloseSlightlyLater (0.10s)
    === RUN   TestInotifyCloseSlightlyLaterWithWatch
    --- PASS: TestInotifyCloseSlightlyLaterWithWatch (0.10s)
    === RUN   TestInotifyCloseAfterRead
    --- PASS: TestInotifyCloseAfterRead (0.10s)
    === RUN   TestInotifyCloseCreate
    --- FAIL: TestInotifyCloseCreate (0.05s)
        inotify_test.go:136: Took too long to wait for event
    === RUN   TestInotifyStress
    --- FAIL: TestInotifyStress (5.00s)
        inotify_test.go:238: Expected at least 50 creates, got 0
    === RUN   TestInotifyRemoveTwice
    --- PASS: TestInotifyRemoveTwice (0.00s)
    === RUN   TestInotifyInnerMapLength
    
    signal: terminated
    FAIL    github.com/go-fsnotify/fsnotify 348.362s
    
    bug linux 
    opened by NightTsarina 39
  • add Solaris FEN support

    add Solaris FEN support

    This pull request fixes #12.

    I'm an employee of Joyent, Inc., and have completed the Google corporate CLA.

    What does this pull request do?

    This pull request adds fsnotify support for Solaris and illumos via Solaris FEN. It is heavily based on #196, authored by @gfrey. As such, and with his approval, I have added @gfrey in the AUTHORS file in addition to myself.

    One major revision to @gfrey's work concerns liveness when the watcher is closed when there is an unconsumed event in the channel - the old pull request would sometimes hang on the TestWatcherClose test. The new concurrency model is borrowed from fsnotify's inotify implementation.

    Another major revision concerns proper translation of FEN events to fsnotify events, in particular the FILE_RENAME_TO FEN event.

    Where should the reviewer start?

    These pages are useful as an introduction to FEN:

    • https://xnet.fi/solaris/
    • https://solarisrants.wordpress.com/2013/07/24/solaris-file-event-notification/

    The illumos man pages for port_create and related functions are also helpful for understanding how to interface with FEN.

    The discussion on #196 is also worth reading. Some points I'll address here:

    • The use of syscall appears necessary here because golang.org/x/sys/unix does not (to my knowledge) provide a way to get atime and ctime.
    • cgo is used because, for illumos, the officially supported interface to the OS is libc rather than syscalls, and thus user-level code should refrain from making syscalls directly.

    How should this be manually tested?

    I ran all tests on a SmartOS host. On SmartOS, Go can be installed from Joyent's pkgsrc repository. fsnotify can then be built and tested as normal.

    illumos 
    opened by isaacdavis 34
  • Could we please get back the master-branch on this repository?

    Could we please get back the master-branch on this repository?

    This request not about anything else but to get our build scripts to run again.

    In our scenario, we use Yocto and its meta-layer meta-virtualization, which includes a script of how to generate this package. Until 12 days ago, the repository from where to pull the codebase was noted as git://github.com/fsnotify/fsnotify.git;branch=master;protocol=https. Since the branch master was removed from this repository, all previous states of the repository cannot be used to build a valid Linux distribution without first having to change the branch name.

    For us this now creates a really big challenge between not being able to build. Solutions we see on our side are getting everything up to date, which would require a ton of time and testing; or to just fork the repo and having to maintain it ourselves from the state we're now on - more maintenance.

    I guess many other people are facing the same problem, where I just want to ask - what's wrong with keeping it called master vs breaking almost any build script which relies on the existence of the branch?

    opened by SimonSimCity 28
  • Final Notice: Maintainers Wanted

    Final Notice: Maintainers Wanted

    This is a final notice. fsnotify is a fork of @howeyc's library that I made many years ago, but I am no longer willing to maintain. To be honest, I have done very little to maintain the project in recent years, so I believe that letting go is the best thing I can do.

    Either new maintainers will take over the project by February 28, 2022, or this project will be archived.

    If the project is archived, the code will still be available for use, but no further changes or issues will be possible. At that point it will be up to the open source community at large to decide whether or not to fork the project.

    Either way, I will be officially leaving the project.

    Things to know about the project

    • According to pkg.go.dev, fsnotify is in use by over 4000 open source packages. Any changes must be carefully considered and semantic versioning must be strictly followed.
    • fsnotify is a low-level library, and many of the issues reported stem from issues with the underlying event notification systems. Whether or not those issues can be solved with code or not, I do not know. It may be that providing better documentation will stave off the same issues being opened repeatedly. 😬
    • fsnotify is a cross-platform library, which means that any API changes must take into account all platforms. GitHub Actions does not cover every platform that fsnotify supports (e.g. BSD), so manual testing on multiple platforms may be necessary.
    • Not every maintainer needs to maintain support for every platform, but it's important that every maintainer is ensuring cross-platform compatibility.
    • There are quite a few open issues, unreviewed pull requests, and the existing code base is rough in spots (especially Windows support).

    How to become a maintainer

    I will not be handing out administrative access to just anyone.

    There are a few ways to show I can trust you to become a maintainer:

    • If you have previously contributed to fsnotify
    • If you are someone I know personally
    • Start helping to triage issues (which are often duplicates) and open pull requests, then come back and ask

    Please comment below. Indicate your name, number of years experience maintaining other open source projects, your primary platform, platforms willing to support, number of hours per week/month you're willing to contribute.

    NOTE: this issue replaces a 5-year old call for maintainers #183

    opened by nathany 28
  • inotify: code cleanup. Closing watcher should now always shut down goroutine

    inotify: code cleanup. Closing watcher should now always shut down goroutine

    fixes go-fsnotify/fsnotify#3

    Also fixed a racey access to w.watches in Close.

    I put the tests in notify_test.go, so it doesn't break any other builds. These tests should be checked against the other platforms one by one before pulling them into integration_test.go.

    opened by PieterD 25
  • Maintainers wanted

    Maintainers wanted

    I think it makes sense to split fsnotify out into smaller platform-specific libraries that fsnotify (or alternatives) can use. Each library needs maintainers to go off and create the library with integration tests and documentation, and to handle issues and code reviews on an ongoing basis.

    • fsevents is one such library, currently in progress (macOS)
    • inotify for Linux is another, see #173 for my thoughts on it
    • Windows also needs a library
    • kqueue for BSD (and macOS, iOS)
    • poller for Plan9, NFS shares, Sharepoint volumes, etc.
    • also FEN for Solaris

    Are you interested?

    related: https://github.com/pickhardt/maintainers-wanted

    letter posted to forum: https://groups.google.com/forum/#!topic/golang-nuts/Ix4sg_gDLNE

    help-wanted 
    opened by nathany 23
  • The fsnotify.WRITE and fsnotify.CHMOD events are generated when a file is changed in arm architecture

    The fsnotify.WRITE and fsnotify.CHMOD events are generated when a file is changed in arm architecture

    Before reporting an issue, please ensure you are using the latest release of fsnotify, and please search for existing issue to avoid duplicates.

    Describe the bug

    issue: https://github.com/kubernetes/kubernetes/issues/103500

    Under ARM64 environment, POD log parameter is the wireless cycle of log after Follow.

    I looked at the kubelet source code and found that kubelet watch for changes to the container log file via fsnotify and outputs the new log to the terminal when new logs are generated.

    https://github.com/kubernetes/kubernetes/blob/fbffe056dd03bd9c746e8819ad22043d640a4489/pkg/kubelet/kuberuntime/logs/logs.go#L438-L454

    My guess is that fsnotify reported the events that did not meet expectations, causing the kubelet to re-read the entire log file each time (original log + new log), so what we see in the terminal is that the log keeps polling for a refresh.

    and I extracted the key code from the kubelet and verified the issue on the arm64 architecture, but the same code works fine on amd64.

    on arm64, fsnotify intermittently reports CHMOD event events, even if there are no new changes to this file, as shown below:

    I0119 16:28:57.247735  904671 main.go:416] fsnotify.Chmod
    I0119 16:28:57.754465  904671 main.go:404] fsnotify.Write
    I0119 16:28:59.720545  904671 main.go:416] fsnotify.Chmod
    I0119 16:28:59.779180  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:00.435542  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:00.493033  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:02.203653  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:02.259917  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:07.215793  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:07.276046  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:10.485498  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:10.545103  904671 main.go:416] fsnotify.Chmod
    I0119 16:29:10.604148  904671 main.go:416] fsnotify.Chmod
    

    on amd64, it work well:

    [[email protected] kubelet]# go run main.go
    I0119 16:36:53.251494 2949984 main.go:534] WebServer Starting on 127.0.0.1:18080...
    I0119 16:37:12.500778 2949984 main.go:286] success to watch file "/var/lib/docker/containers/bd965f51b1d1a255262e287e0b6a78e322f68c198991b28a7563e21caf28677f/bd965f51b1d1a255262e287e0b6a78e322f68c198991b28a7563e21caf28677f-json.log"
    I0119 16:37:18.223509 2949984 main.go:404] fsnotify.Write
    I0119 16:37:26.417523 2949984 main.go:404] fsnotify.Write
    

    Can anyone help me? I don't know what's causing this,Thanks!

    To Reproduce

    wecom-temp-2f08e0a10e1f8406a39e5278f360fa90

    Expected behavior A clear and concise description of what you expected to happen.

    When the file changes, fsnotify reports the correct event instead of always reporting the CHMOD event

    Which operating system and version are you using?

    [[email protected] kubelet-fsnotify]# uname -a
    Linux dce-18-18-10-202 4.19.90-23.8.v2101.ky10.aarch64 #1 SMP Mon May 17 17:07:38 CST 2021 aarch64 aarch64 aarch64 
    GNU/Linux
    

    Additional context If applicable, add screenshots or a code sample to help explain your problem.

    bug linux help-wanted need-feedback 
    opened by cyclinder 22
  • Add support for solaris FEN

    Add support for solaris FEN

    Fixes #12 I've signed the CLA.

    What does this pull request do?

    This is a basic implementation of fsnotify for Solaris FEN. It at least passes all integration tests.

    Where should the reviewer start?

    I used the following two resource to get a basic understanding how this should work:

    • https://solarisrants.wordpress.com/2013/07/24/solaris-file-event-notification/
    • https://blogs.oracle.com/praks/entry/file_events_notification

    How should this be manually tested?

    The available integration tests are enabled for solaris now and succeed.

    illumos help-wanted 
    opened by gfrey 20
  • kqueue: wait without timeout

    kqueue: wait without timeout

    As noted in #24, reading from the kqueue won't unblock when it is closed on all platforms. This commit solves the issue by additionally watching on a pipe which is closed when Watcher is closed. This makes the read timeout unnecessary.

    macOS freebsd 
    opened by fjl 19
  • Panic on Mac OS X when debugging

    Panic on Mac OS X when debugging

    Before reporting an issue, please ensure you are using the latest release of fsnotify.

    Which operating system (GOOS) and version are you using?

    OS: ProductName: Mac OS X ProductVersion: 10.12.5 BuildVersion: 16F73

    Go: go version go1.8.3 darwin/amd64

    Delve: Delve Debugger Version: 1.0.0-rc.1 Build:

    IDE: Visual Studio Code Ver 1.14.1 (1.14.1) 2648980a697a4c8fb5777dcfb2ab110cec8a2f58 2017-07-13T19:05:02.227Z

    Please describe the issue that occurred.

    When execution continues after stop at breakpoint then panic raised at kqueue.go -> read(kq int, events []unix.Kevent_t, timeout *unix.Timespec)

    Are you able to reproduce the issue? Please provide steps to reproduce and a code sample if possible.

    1. I use sample code from https://github.com/fsnotify/fsnotify/blob/master/example_test.go
    2. Set up breakpoint at any place
    3. Trigger breakpoint
    4. When step over or continue execution then panic raised
    panic: runtime error: slice bounds out of range
    
    goroutine 8 [running]:
    bitbucket.org/project/vendor/github.com/fsnotify/fsnotify.read(0x8, 0xc4202e0e88, 0xa, 0xa, 0x1708c50, 0xc4202e0e88, 0x0, 0xa, 0x0, 0x0)
    
    /path_to_project/vendor/github.com/fsnotify/fsnotify/kqueue.go:498 +0x2fe
    bitbucket.org/litkiosk/litkiosk_server/vendor/github.com/fsnotify/fsnotify.(*Watcher).readEvents(0xc42001c360)
    
    /path_to_project/vendor/github.com/fsnotify/fsnotify/kqueue.go:284 +0xda
    created by bitbucket.org/litkiosk/litkiosk_server/vendor/github.com/fsnotify/fsnotify.NewWatcher
    
    /path_to_project/vendor/github.com/fsnotify/fsnotify/kqueue.go:62 +0x2c8
    

    I added log in this function

    func read(kq int, events []unix.Kevent_t, timeout *unix.Timespec) ([]unix.Kevent_t, error) {
    	n, err := unix.Kevent(kq, nil, events, timeout)
    	if err != nil {
    		return nil, err
    	}
    	fmt.Println("n", n, "len", len(events), "cap", cap(events))
    	return events[0:n], nil
    }
    

    and it prints

    n 0 len 10 cap 10
    n 0 len 10 cap 10
    n 0 len 10 cap 10
    n 0 len 10 cap 10
    2017/07/15 12:00:40 debugger.go:505: continuing
    n 33554795 len 10 cap 10
    
    bug freebsd help-wanted need-feedback 
    opened by NightBlaze 18
  • inotify: simplify bookkeeping of watched paths

    inotify: simplify bookkeeping of watched paths

    Create a new watches type to keep track of the watches instead of keeping two maps on the Watcher and accessing these directly.

    This makes the bookkeeping a bit easier to follow, and we no longer need to worry about locking map access as the watcher type takes care of that now.

    Came up in #472 where I want to keep track if a path was added recursively, and this makes that a bit easier.

    Also seems a bit faster:

    BenchmarkWatch-2          903709              7122 ns/op             194 B/op          3 allocs/op
    BenchmarkWatch-2          923980              6322 ns/op             196 B/op          3 allocs/op
    

    Although that benchmark is very simple and only tests one code path; just want to make sure it's not a horrible regression.

    opened by arp242 0
  • Fanotify Support

    Fanotify Support

    Initial work on adding fanotify support. Much of the code is from https://github.com/opcoder0/fanotify.

    These are some of the things that are on my to do list -

    • Adding features for these fanotify flags:
    • unix.FAN_UNLIMITED_QUEUE
    • unix.FAN_UNLIMITED_MARKS
    • unix.FAN_REPORT_TID
    • unix.FAN_ENABLE_AUDIT
    • I have not yet been able to test on certain kernel versions to test the need for getFileHandle and getFileHandleWithName.
    • Figure out how to wire fanotify tests into the current structure (requires CAP_SYS_ADMIN).
    • Figure out how to get the docs show up correctly.
    • Add examples

    In addition to any other comments, I would appreciate feedback on the APIs as I am not sure how to maintain the API compatability with inotify and fanotify.

    Closes #114

    opened by opcoder0 7
  • Intermittent test failures

    Intermittent test failures

    I've seen some intermittent test failures on the CI; these may be bugs in fsnotify or the test case.

    test (ubuntu-latest, 1.19): https://github.com/fsnotify/fsnotify/actions/runs/3475789919/jobs/5810388516

    --- FAIL: TestInotifyDeleteOpenFile (0.62s)
    	backend_inotify_test.go:97: 
    		have:
    			
    		want:
    			CHMOD                "/file"
    	backend_inotify_test.go:101: 
    		have:
    			CHMOD                "/file"
    			REMOVE               "/file"
    		want:
    			REMOVE               "/file"
    
    opened by arp242 5
  • Export addOpt

    Export addOpt

    Is your feature request related to a problem? Please describe. addOpt appears in the public API, yet it's unexported.

    If someone wanted to implement a watcher outside of this library (for example prior to 1.7.0 that's the only way to make fsnotify-dependent libraries compile on unsupported platforms, see #528) and use AddWith, they can't.

    Describe the solution you'd like Export addOpt so AddWith can be implemented by watchers external to this library.

    Additional context Another reason why someone would want to implement a custom watcher if they wanted to wrap fsnotify watchers.

    Or if someone created an interface to implement alternate implementations.

    There are prefectly valid use cases for this.

    Also, unless addOpt is experimental for some reason, exporting it is safe as it's only used internally with an unexported type.

    I'll add though that generally defining an interface for this purpose is more elegant:

    type AddOpt interface{
        apply(o *withOpts)
    }
    

    Having an interface that can't be implemented is more elegant IMO than an exported function that cannot be called.

    opened by sagikazarmark 1
  • Fix symlink behaviour on kqueue

    Fix symlink behaviour on kqueue

    There were two problems here:

    • When we see a link inside a directory the resolved version would get added to w.watches etc. but the link won't, resulting in many spurious create events for the link. This fixes #277; I'm surprised there aren't more reports for this).

    • filepath.EvalSymlinks() will resolve any symlinks in the entire path, rather than just the link itself. This would cause paths such as:

      /path/to/LINK/dir/dir/WATCH-THIS
      

      To have the wrong Event.Name; many of the test cases failed because of this because /tmp is a link to /private/tmp on macOS, but curiously no one reported it AFAIK (I guess many people don't use symlinks all that much).

      Example:

      % mkdir /tmp/xxx
      % touch /tmp/xxx/FILE
      
      % ln -s /tmp/xxx/LINK /tmp/xxx/FILE   # 25 years of Unix experience, and still...
      ln: /tmp/xxx/FILE: File exists
      % ln -s /tmp/xxx/FILE /tmp/xxx/LINK
      

      Before it would do:

      % go run ./cmd/fsnotify watch /tmp/xxx &
      % touch /tmp/xxx/FILE
      03:23:03.2731   1 CHMOD         "/private/tmp/xxx/FILE"
      03:23:03.2744   2 CHMOD         "/tmp/xxx/FILE"
      ^C
      
      % fsnotify watch /tmp/xxx/LINK &
      % touch /tmp/xxx/LINK
      03:26:37.3576   1 CHMOD         "/private/tmp/xxx/FILE"
      

      And now it does:

      % go run ./cmd/fsnotify watch /tmp/xxx &
      03:23:47.8911   1 CHMOD         "/tmp/xxx/FILE"
      ^C
      
      % fsnotify watch /tmp/xxx/LINK &
      % touch /tmp/xxx/LINK
      03:27:38.5227   1 CHMOD         "/tmp/xxx/FILE"
      
    opened by arp242 1
  • Support additional event types

    Support additional event types

    We only have Create, Remove, Rename, Write, and Chmod now, but many watchers support additional events. This has come up a few times:

    • #24 - Extend, Link, Revoke
    • #297 - Unmount
    • #346 - Read
    • #504 - Open, Close
    • Probably some others?

    Instead of creating a bunch of issues for every possible event, track them here.

    All of this depends on #7; we don't want to spam people with e.g. Open and Close events when they're not interested in them (which is most of the time), and some events aren't supported on all platforms.

    feature 
    opened by arp242 1
Releases(v1.6.0)
  • v1.6.0(Oct 13, 2022)

    This version of fsnotify needs Go 1.16 (this was already the case since 1.5.1, but not documented). It also increases the minimum Linux version to 2.6.32.

    Additions

    • all: add Event.Has() and Op.Has() (#477)

      This makes checking events a lot easier; for example:

        if event.Op&Write == Write && !(event.Op&Remove == Remove) {
        }
      

      Becomes:

        if event.Has(Write) && !event.Has(Remove) {
        }
      
    • all: add cmd/fsnotify (#463)

      A command-line utility for testing and some examples.

    Changes and fixes

    • inotify: don't ignore events for files that don't exist (#260, #470)

      Previously the inotify watcher would call os.Lstat() to check if a file still exists before emitting events.

      This was inconsistent with other platforms and resulted in inconsistent event reporting (e.g. when a file is quickly removed and re-created), and generally a source of confusion. It was added in 2013 to fix a memory leak that no longer exists.

    • all: return ErrNonExistentWatch when Remove() is called on a path that's not watched (#460)

    • inotify: replace epoll() with non-blocking inotify (#434)

      Non-blocking inotify was not generally available at the time this library was written in 2014, but now it is. As a result, the minimum Linux version is bumped from 2.6.27 to 2.6.32. This hugely simplifies the code and is faster.

    • kqueue: don't check for events every 100ms (#480)

      The watcher would wake up every 100ms, even when there was nothing to do. Now it waits until there is something to do.

    • macos: retry opening files on EINTR (#475)

    • kqueue: skip unreadable files (#479)

      kqueue requires a file descriptor for every file in a directory; this would fail if a file was unreadable by the current user. Now these files are simply skipped.

    • windows: fix renaming a watched directory if the parent is also watched (#370)

    • windows: increase buffer size from 4K to 64K (#485)

    • windows: close file handle on Remove() (#288)

    • kqueue: put pathname in the error if watching a file fails (#471)

    • inotify, windows: calling Close() more than once could race (#465)

    • kqueue: improve Close() performance (#233)

    • all: various documentation additions and clarifications.

    Source code(tar.gz)
    Source code(zip)
  • v1.5.4(Apr 27, 2022)

    What's Changed

    • Fix compilation for OpenBSD by @mattn in https://github.com/fsnotify/fsnotify/pull/443
    • go.mod: use latest x/sys by @kevinburkesegment in https://github.com/fsnotify/fsnotify/pull/444
    • README.md: link to pkg.go.dev for golang.org/x/sys package by @tklauser in https://github.com/fsnotify/fsnotify/pull/441
    • Windows: add missing defer to Watcher.WatchList by @Sojamann in https://github.com/fsnotify/fsnotify/pull/447
    • Prepare for v1.5.4 by @shogo82148 in https://github.com/fsnotify/fsnotify/pull/448

    New Contributors

    • @mattn made their first contribution in https://github.com/fsnotify/fsnotify/pull/443
    • @kevinburkesegment made their first contribution in https://github.com/fsnotify/fsnotify/pull/444
    • @Sojamann made their first contribution in https://github.com/fsnotify/fsnotify/pull/447

    Full Changelog: https://github.com/fsnotify/fsnotify/compare/v1.5.2...v1.5.4

    Source code(tar.gz)
    Source code(zip)
  • v1.5.2(Apr 27, 2022)

    What's Changed

    • Removed dead link by @COil in https://github.com/fsnotify/fsnotify/pull/337
    • Update issue templates by @nathany in https://github.com/fsnotify/fsnotify/pull/410
    • Test on Go 1.18 and two most recent versions by @nathany in https://github.com/fsnotify/fsnotify/pull/411
    • fix go vet warnings: call to (*T).Fatalf from a non-test goroutine by @shogo82148 in https://github.com/fsnotify/fsnotify/pull/416
    • Run cross-compilation builds on every push by @nshalman in https://github.com/fsnotify/fsnotify/pull/420
    • Don't set poller.fd twice in newFdPoller by @tklauser in https://github.com/fsnotify/fsnotify/pull/406
    • Re-enable tests for PRs by @nshalman in https://github.com/fsnotify/fsnotify/pull/415
    • Enable cross-compilation builds on PRs by @nshalman in https://github.com/fsnotify/fsnotify/pull/423
    • Integration Tests: change 1ms sleeps to 50ms by @nshalman in https://github.com/fsnotify/fsnotify/pull/422
    • Add FreeBSD testing in Github Actions (fix #389) by @r-darwish in https://github.com/fsnotify/fsnotify/pull/419
    • Allow build on unsupported GOOS by @tklauser in https://github.com/fsnotify/fsnotify/pull/424
    • Fix potential crash on windows if raw.FileNameLength exceeds syscall.MAX_PATH by @hu13 in https://github.com/fsnotify/fsnotify/pull/361
    • Add a feature to return the directories and files that are being monitored by @NitroCao in https://github.com/fsnotify/fsnotify/pull/374

    New Contributors

    • @COil made their first contribution in https://github.com/fsnotify/fsnotify/pull/337
    • @r-darwish made their first contribution in https://github.com/fsnotify/fsnotify/pull/419
    • @hu13 made their first contribution in https://github.com/fsnotify/fsnotify/pull/361
    • @NitroCao made their first contribution in https://github.com/fsnotify/fsnotify/pull/374

    Full Changelog: https://github.com/fsnotify/fsnotify/compare/v1.5.1...v1.5.2

    Source code(tar.gz)
    Source code(zip)
  • v1.5.1(Aug 24, 2021)

  • v1.5.0(Aug 18, 2021)

    • Go: Increase minimum required version to Go 1.12 #381
    • Feature: Add AddRaw method which does not follow symlinks when adding a watch #289
    • Windows: Follow symlinks by default like on all other systems #289
    • CI: Use GitHub Actions for CI and cover go 1.12-1.17 #378 #381 #385
    • Go 1.14+: Fix unsafe pointer conversion #325
    Source code(tar.gz)
    Source code(zip)
  • v1.4.9(Mar 11, 2020)

  • v1.4.8(Mar 10, 2020)

    • CI: test more go versions (@nathany 1d13583d846ea9d66dcabbfefbfb9d8e6fb05216)
    • Tests: Queued inotify events could have been read by the test before max_queued_events was hit (@matthias-stone #265)
    • Tests: t.Fatalf -> t.Errorf in go routines (@gdey #266)
    • CI: Less verbosity (@nathany #267)
    • Tests: Darwin: Exchangedata is deprecated on 10.13 (@nathany #267)
    • Tests: Check if channels are closed in the example (@alexeykazakov #244)
    • CI: Only run golint on latest version of go and fix issues (@cpuguy83 #284)
    • CI: Add windows to travis matrix (@cpuguy83 #284)
    • Docs: Remover appveyor badge (@nathany 11844c0959f6fff69ba325d097fce35bd85a8e93)
    • Linux: create epoll and pipe fds with close-on-exec (@JohannesEbke #219)
    • Linux: open files with close-on-exec (@linxiulei #273)
    • Docs: Plan to support fanotify (@nathany ab058b44498e8b7566a799372a39d150d9ea0119 )
    • Project: Add go.mod (@nathany #309)
    • Project: Revise editor config (@nathany #309)
    • Project: Update copyright for 2019 (@nathany #309)
    • CI: Drop go1.8 from CI matrix (@nathany #309)
    • Docs: Updating the FAQ section for supportability with NFS & FUSE filesystems (@Pratik32 4bf2d1fec78374803a39307bfb8d340688f4f28e )
    Source code(tar.gz)
    Source code(zip)
  • v1.4.7(Jan 10, 2018)

    • BSD/macOS: Fix possible deadlock on closing the watcher on kqueue (thanks @nhooyr and @glycerine)
    • Tests: Fix missing verb on format string (thanks @rchiossi)
    • Linux: Fix deadlock in Remove (thanks @aarondl)
    • Linux: Watch.Add improvements (avoid race, fix consistency, reduce garbage) (thanks @twpayne)
    • Docs: Moved FAQ into the README (thanks @vahe)
    • Linux: Properly handle inotify's IN_Q_OVERFLOW event (thanks @zeldovich)
    • Docs: replace references to OS X with macOS
    Source code(tar.gz)
    Source code(zip)
  • v1.4.2(Oct 11, 2016)

    Linux: use InotifyInit1 with IN_CLOEXEC to stop leaking a file descriptor to a child process when using fork/exec #178 (thanks @pattyshack)

    Source code(tar.gz)
    Source code(zip)
  • v1.4.1(Oct 5, 2016)

  • v1.4.0(Oct 2, 2016)

  • v1.3.1(Jun 29, 2016)

  • v1.3.0(Apr 20, 2016)

    Support linux/arm64 by patching x/sys/unix and switching to to it from syscall #135 (thanks @suihkulokki)

    Please see the README for updated information on installation.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.10(Mar 3, 2016)

  • v1.2.9(Jan 14, 2016)

  • v1.2.8(Dec 17, 2015)

    • kqueue: fix race condition in Close #105 (thanks @djui for reporting the issue and @ppknap for writing a failing test)
    • inotify: fix race in test
    • enable race detection for continuous integration (Linux, Mac, Windows)
    Source code(tar.gz)
    Source code(zip)
  • v1.2.5(Nov 17, 2015)

    • inotify: use epoll_create1 for arm64 support (requires Linux 2.6.27 or later) #100 (thanks @suihkulokki)
    • inotify: fix path leaks #73 (thanks @chamaken)
    • kqueue: watch for rename events on subdirectories #83 (thanks @guotie)
    • kqueue: avoid infinite loops from symlinks cycles #101 (thanks @illicitonion)
    Source code(tar.gz)
    Source code(zip)
  • v1.2.1(Oct 14, 2015)

  • v1.2.0(Feb 8, 2015)

    This releases resolves several issues when Close() is used, from leaking file descriptors to blocking issues. It also is using epoll when reading events on Linux to avoid blocking.

    • inotify: use epoll to wake up readEvents #66 #5 (thanks @PieterD)
    • inotify: deleted file watches can now be removed #40
    • inotify: closing watcher should now always shut down goroutine #63 (thanks @PieterD)
    • kqueue: close kqueue after removing watches, fixes #59
    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Feb 6, 2015)

  • v0.9.3(Jan 1, 2015)

  • v1.1.0(Dec 13, 2014)

    kqueue

    • rework internals #43
    • add low-level functions
    • only need to store flags on directories
    • less mutexes #13
    • done can be an unbuffered channel
    • remove calls to os.NewSyscallError
    • fix regression in rework causing subdirectories to be watched #48
    • cleanup internal watch before sending remove event #51

    other

    • More efficient string concatenation for Event.String() #52 (thanks @mdlayher)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.4(Sep 8, 2014)

    • kqueue: add dragonfly to the build tags.
    • Rename source code files, rearrange code so exported APIs are at the top.
    • Add done channel to example code. (thanks @chenyukang)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.3(Aug 20, 2014)

  • v1.0.2(Aug 17, 2014)

  • v0.9.2(Aug 17, 2014)

  • v1.0.0(Aug 17, 2014)

    • Improve documentation for exported identifiers. #30
    • Minor updates based on feedback from golint.

    v1 contains a number of API changes and improvements over v0.9.0. See the CHANGELOG for the full details.

    Source code(tar.gz)
    Source code(zip)
Owner
fsnotify
File system notifications for Go.
fsnotify
cross-platform, normalized battery information library

battery Cross-platform, normalized battery information library. Gives access to a system independent, typed battery state, capacity, charge and voltag

null 213 Dec 22, 2022
Neko is a cross-platform open-source animated cursor-chasing cat. This is the reimplementation write in Go.

Neko Neko is a cat that chases the mouse cursor across the screen, an app written in the late 1980s and ported for many platforms. This code is a re-i

Cesar Gimenes 49 Nov 21, 2022
Chief Client Go is a cross platform Krunker client written in Go Lang

Chief Client Go Chief Client Go is a client for Mac and Linux written in GoLang Features Ad Blocker Option to use proxy Installation To install this c

Chief Software 0 Nov 6, 2021
Simple cross platform fetch program, written in Go

nextfetch Simple cross platform fetch program, written in Go Prerequisites True color (24-bit) or 256-color (8-bit) compatible terminals go >= 17 (bui

Nguyen Thanh Quang 3 Oct 31, 2022
An efficient Go Rapid Product Assembly system used within the Bhojpur.NET Platform ecosystem.

Bhojpur GoRPA - Builder, Packager, Assembler An efficient Go-based Rapid Product Assembly software tool used within the Bhojpur.NET Platform ecosystem

Bhojpur Consulting 0 Apr 28, 2022
The Bhojpur BSS is a software-as-a-service product used as an Business Support System based on Bhojpur.NET Platform for application delivery.

Bhojpur BSS - Business Support System The Bhojpur BSS is a software-as-a-service product used as an Business Support System based on Bhojpur.NET Platf

Bhojpur Consulting 0 Sep 26, 2022
File system event notification library on steroids.

notify Filesystem event notification library on steroids. (under active development) Documentation godoc.org/github.com/rjeczalik/notify Installation

Rafal Jeczalik 790 Jan 7, 2023
Simple Golang API to demonstrate file upload to fireabase storage and retrieving url of uploaded file.

go-firebase-storage -Work in progress ??️ Simple Golang API that uses Firebase as its backend to demonstrate various firebase services using Go such a

Victor Kabata 4 Oct 4, 2021
Works with HashiCorp HCL. Allows to append the input file with blocks and attributes from the template file

About hclmergetool Works with HashiCorp HCL. Allows to append the input file with blocks and attributes from the template file Installation Binary Rel

Max Fedorov 0 Feb 6, 2022
An example client implementation written in GO to access the CyberVox platform API

About This is an example client implementation written in GO to access the CyberVox platform API.

Cyberlabs AI 15 Nov 7, 2022
Complete container management platform

Rancher Rancher is an open source project that provides a container management platform built for organizations that deploy containers in production.

Rancher 20.4k Jan 8, 2023
golang script for bypass AV and work only in windows platform

antivirus bypass protection requirements golang installed usage 1 - create your payload go run create.go <ip> <port> <secret> <any url>

null 29 Nov 9, 2022
A comprehensive training, nutrition, and social platform for martial artists and combat sport athletes

COMHRAC Comhrac (Gaelic for "Combat") is a comprehensive training, nutrition, and social platform for martial artists and combat sport athletes. Devel

Jack Hegarty 0 Oct 17, 2021
Elytrium Billing: Module-based billing platform made with Go

In development Elling - Elytrium Billing Module-based billing platform made with Go The main idea of this product - make a stable billing platform for

Elytrium 1 Jun 4, 2022
Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging

Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging and plugins to provide users with a much stronger, more integrated experience than the loose coupling and stand-alone commands of the previous generation of tools.

VMware Tanzu 188 Dec 16, 2022
:chart_with_upwards_trend: Monitors Go MemStats + System stats such as Memory, Swap and CPU and sends via UDP anywhere you want for logging etc...

Package stats Package stats allows for gathering of statistics regarding your Go application and system it is running on and sent them via UDP to a se

Go Playgound 163 Nov 10, 2022
Real-time Charging System for Telecom & ISP environments

Real-time Online/Offline Charging System (OCS) for Telecom & ISP environments Features Real-time Online/Offline Charging System (OCS). Account Balance

null 368 Dec 31, 2022
go language generics system

Gotgo This document describes the third iteration of my attempt at a reasonable implementation of generics for go based on the idea of template packag

David Roundy 118 Dec 31, 2022
Mobile Blogging System

Mobile Blogging System

mattn 18 Mar 3, 2022