diff --git a/.editorconfig b/.editorconfig deleted file mode 100644 index ba49e3c..0000000 --- a/.editorconfig +++ /dev/null @@ -1,5 +0,0 @@ -root = true - -[*] -indent_style = tab -indent_size = 4 diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md deleted file mode 100644 index 0d76be3..0000000 --- a/.github/ISSUE_TEMPLATE.md +++ /dev/null @@ -1,9 +0,0 @@ -Before reporting an issue, please ensure you are using the latest release of fsevents. - -### Which version of macOS are you using? - -Replace this line with the output of running sw_vers on the command line. - -### Please describe the issue that occurred. - -### Are you able to reproduce the issue? Please provide steps to reproduce and a code sample if possible. diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md deleted file mode 100644 index 64ddf7c..0000000 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ /dev/null @@ -1,8 +0,0 @@ -#### What does this pull request do? - - -#### Where should the reviewer start? - - -#### How should this be manually tested? - diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index ccf8613..c90776c 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -1,55 +1,37 @@ -name: test -on: [push] +name: 'test' +on: ['push', 'pull_request'] jobs: test: strategy: fail-fast: false matrix: - os: - - macos-10.15 - - macos-latest - go: - - '1.18.0-beta1' - - '1.17' - - '1.16' + os: ['macos-12', 'macos-latest'] + go: ['1.17', '1.22'] runs-on: ${{ matrix.os }} steps: - - name: setup Go - uses: actions/setup-go@v2 + - uses: 'actions/checkout@v4' + - uses: 'actions/setup-go@v5' with: - stable: 'false' - go-version: ${{ matrix.go }} + go-version: '${{ matrix.go }}' + - name: 'test' + run: 'go test --race ./...' - - name: checkout - uses: actions/checkout@v2 - - - name: test - run: | - go test --race ./... - - lint: - runs-on: macos-latest + staticcheck: + name: 'staticcheck' + runs-on: 'macos-latest' steps: - - name: setup Go - uses: actions/setup-go@v2 - with: - go-version: '1.17' - - - name: checkout - uses: actions/checkout@v2 - - - name: gofmt - run: | - test -z "$(gofmt -s -d . | tee /dev/stderr)" - - - name: vet - run: | - go vet ./... - - - name: golangci-lint - uses: golangci/golangci-lint-action@v2 - continue-on-error: true + - uses: 'actions/checkout@v4' + - uses: 'actions/setup-go@v5' with: - version: latest - skip-go-installation: true - + go-version: '1.22' + - uses: 'actions/cache@v4' + with: + key: '${{ runner.os }}-staticcheck' + path: | + ${{ runner.temp }}/staticcheck + ${{ steps.install_go.outputs.GOCACHE || '' }} + + - run: | + export STATICCHECK_CACHE="${{ runner.temp }}/staticcheck" + go install honnef.co/go/tools/cmd/staticcheck@latest + $(go env GOPATH)/bin/staticcheck ./... diff --git a/AUTHORS b/AUTHORS deleted file mode 100644 index e5d8d72..0000000 --- a/AUTHORS +++ /dev/null @@ -1,22 +0,0 @@ -# Names should be added to this file as -# Name or Organization -# The email address is not required for organizations. - -# You can update this list using the following command: -# -# $ git shortlog -se | awk '{print $2 " " $3 " " $4}' - -# Please keep the list sorted. - -Adrian Serrano -Andrew Metcalf -Drew Wells -Jeremy Jay -Koichi Shiraishi -Lachlan Donald -Matthias Kadenbach -Nathan Youngman -Sam Jacobson -Scott Albertson -Wade Simmons -alessandrozucca diff --git a/INTERNALS.md b/INTERNALS.md deleted file mode 100644 index ff64b28..0000000 --- a/INTERNALS.md +++ /dev/null @@ -1,84 +0,0 @@ -# Really quick FSEvents overview - -For those new to FSEvents itself (the Apple technology), here's a really quick primer: - -Introduced in macOS v10.5, File System Events is made up of three parts: - -* kernel code that passes raw event data to user space through a special device -* a daemon that filters this stream and sends notifications -* a database that stores a record of all changes - -The API provides access to this system allowing applications to be notified of changes to directory hierarchies, and also to retrieve a history of changes. File System Events are path / file name based, *not* file descriptor based. This means that if you watch a directory (path) and it is moved elsewhere your watch does not automatically move with it. - -The API uses the concept of a *Stream* (FSEventStream) which is a configurable stream of notifications. A Stream can recursively monitor many directories. Options like latency which allow the coalescing of events are specific to one stream. - -## Persistent Monitoring - -The database kept by the File System Events API allow a program that is run periodically to check for changes to the file system between runs. This has a real impact on the API and why there are parameters like `since`. This feature should be considered *advisory* according to Apple's docs - a full scan should still be run periodically. If an older version of macOS modifies the file system (say, by removing the drive and putting it in another computer) it would not update the database. - -The `since` parameter must be an EventID for the host or device that the stream is for (or the special ALL or NOW values). - -To discover the EventID at a specific time the function `LastEventBefore` can be used (calls `FSEventsGetLastEventIdForDeviceBeforeTime`); provide dev==0 for a host EventID. Current() (calls FSEventsGetCurrentEventId) returns the most recent EventID. - -## Apple Docs - -* [FSEvents_ProgGuide.pdf][https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/FSEvents_ProgGuide/FSEvents_ProgGuide.pdf] -* [FSEvents_ProgGuide html][https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005289-CH1-SW1] - -## Device Streams vs Host Streams - -A Host Stream (dev == 0) can monitor directories through the entire system (assuming appropriate permissions). EventIDs increase across all devices (i.e. an older event on any device has a smaller EventID than a newer one except when EventID's rollover). This means that if another disk is added / mounted then there is the potential for a historical EventID conflict. - -A Device Stream (pass a `Device` to `New`) can monitor directories only on the given device. Because the EventIDs refer only to that device there is no chance of conflict. - -For real-time monitoring there aren't any notable advantages to a Device Stream over a Host stream. For persistent monitoring (run a program today to see what changed yesterday) Device Streams are more robust since there can be no EventID conflict. - -## File Events - -Is macOS v10.7 Apple introduced *File Events* (kFSEventStreamCreateFlagFileEvents aka CF_FILEEVENTS). Prior to this events are delivered for directories only, i.e. if /tmp/subdir/testfile is modified and an FSEventStream is monitoring /tmp then an event would be delivered for the path /tmp/subdir. This tells the application that it should scan /tmp/subdir for changes. It was also possible (in corner cases) that an event for the path /tmp could be created with MUSTSCANSUBDIRS set. This should only happen if events are being dropped, and had to be coalesced to prevent the loss of information. - -With CF_FILEEVENTS set (>= macOS v10.7) events are generated with the path specifying the individual files that have been modified. I haven't found explicit mention, but it seems likely that the same caveats apply with respect to coalescing if events are being dropped. - -Apple warns that using File Events will cause many more events to be generated (in part, I expect, because they don't coalesce as easily as directory-level events). - -## Temporal Coalescing - -If two files in the same directory are changed in a short period of time (e.g. /tmp/test1 and /tmp/test2) (assuming CF_FILEEVENTS=0) a single event could be delivered to the application specifying that the path `/tmp` contains changes. There is an efficiency boost when scanning /tmp only once looking for all changes versus scanning it once for test1 and once for test2. The `latency` parameter enables this kind of temporal coalescing. If `latency` is set to, say, 1 second then the application will not be notified more than once a second about changes. The flag kFSEventStreamCreateFlagNoDefer aka CF_NODEFER specifies whether the application is notified on the leading or lagging edge of changes. - -# Structure of fsevents.go - -### Creating a Stream - -`EventStream` encapsulates an FSEventStream, and allows an arbitrary number of paths to be monitored. - -For real-time monitoring an EventStream is created with `Resume` == `false`. This means it will not deliver historical events. If `Resume` == `true` then all recorded events for the supplied paths since `EventId` would be supplied first, then realtime events would be supplied as they occur. - -The `Latency` parameter is passed on to the API, and used to throttle / coalesce events - '0' means deliver all events. - -`Device` can be used to create streams specific to a device, (See Device Streams vs Host Streams). Use '0' to create a host stream. - -Instantiating an `EventStream` just allocates memory to store the *configuration* of the stream. Calling `EventStream.Start` creates the FSEventStream, and a channel that will be used to report events `EventStream.Events` (unless one has already been supplied). The EventStream is stored (via an unsafe.Pointer) in the FSEventStream context (so the OS callback has access to it). - -### Running a Stream - -In macOS an application must run a RunLoop (see: [Run Loop Management][https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html#//apple_ref/doc/uid/10000057i-CH16-SW1]) for each thread that wishes to receive events from the operating system. - -An FSEventStream needs to be started, and must be supplied with a Runloop reference to deliver events to. - -To accomplish this `EventStream.Start` creates a goroutine that calls CFRunLoopRun(). The call in to CFRunLoopRun does not return until the runloop is stopped by `EventStream.Stop`. I _believe_ that the current implementation will work correctly because of the following: - -* There is a many->one mapping from goroutines to os threads (i.e. goroutines do not switch os-threads). -* The os thread that runs the Run Loop will not be available for other goroutines because CFRunLoopRun does not return. -* This therefore means that each call to `EventStream.Start` will consume an OS thread until the runloop is stopped by `EventStream.Stop` calling CFRunLoopStop. Each Stream will get it's own Run Loop (on it's own OS thread). - -### Receiving Events - -The File System Events API causes a C-callback to be called by delivering an event. The callback extracts / converts the supplied data then posts an array of `Event`s on the channel `EventStream.Events`. The `EventStream` is stored in the context parameter of the FSEventStream (supplied back to the callback by the File System Events API). - -### Stopping a Stream - -`EventStream.Stop` stops and invalidates the stream (as per the File System Events API requirements), then releases the Stream memory, and stops the runloop that was started by `EventStream.Start`. This returns the `EventStream` to (almost) the same state as before `EventStream.Start` was called. The difference is that `EventStream.EventID` is now set to the last event ID received before the stream was stopped, and `EventStream.Events` will now reference an instantiated channel (it may have been nil before the call to `EventStream.Start`). - -### Memory / Callback Safety - -`EventStream` manages some OS resources (an OS thread, an FSEventStream, an OS runloop, etc). If the `EventStream` is garbage collected without the being stopped then a panic is likely. This is caused by an FSEventStream callback attempting to reference the `EventStream` via an `unsafe.Pointer`. To guard against this situation a finalizer is attached to the `EventStream` when it is started. When the finalizer triggers (through GC of the `EventStream`) it stops the stream so that the OS resources can be freed. This prevents the panic. diff --git a/LICENSE b/LICENSE index cb53e5f..47a2bd9 100644 --- a/LICENSE +++ b/LICENSE @@ -1,4 +1,4 @@ -Copyright (c) 2014 The fsevents Authors. All rights reserved. +Copyright © The fsevents Authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are diff --git a/README.md b/README.md index 83829a6..6c2e972 100644 --- a/README.md +++ b/README.md @@ -1,20 +1,203 @@ -# FSEvents bindings for Go (macOS) +[FSEvents] allows an application to monitor a whole file system or portion of +it. FSEvents is only available on macOS. -[![GoDoc](https://godoc.org/github.com/fsnotify/fsevents?status.svg)](https://godoc.org/github.com/fsnotify/fsevents) [![Reviewed by Hound](https://img.shields.io/badge/Reviewed_by-Hound-8E64B0.svg)](https://houndci.com) - -[FSEvents](https://developer.apple.com/documentation/coreservices/file_system_events) allows an application to monitor a whole file system or portion of it. FSEvents is only available on macOS. +Godoc: https://pkg.go.dev/github.com/fsnotify/fsevents **Warning:** This API should be considered unstable. -## Caveats +[FSEvents]: https://developer.apple.com/documentation/coreservices/file_system_events +Caveats +======= Known caveats of the macOS FSEvents API which this package uses under the hood: - - FSEvents returns events for the named path only, so unless you want to follow updates to a symlink itself (unlikely), you should use `filepath.EvalSymlinks` to get the target path to watch. - - There is an internal macOS limitation of 4096 watched paths. Watching more paths will result in an error calling `Start()`. Note that FSEvents is intended to be a recursive watcher by design, it is actually more efficient to watch the containing path than each file in a large directory. +- FSEvents returns events for the named path only, so unless you want to follow + updates to a symlink itself (unlikely), you should use `filepath.EvalSymlinks` + to get the target path to watch. + +- There is an internal macOS limitation of 4096 watched paths. Watching more + paths will result in an error calling `Start()`. Note that FSEvents is + intended to be a recursive watcher by design, it is actually more efficient to + watch the containing path than each file in a large directory. + +Contributing +============ +FSEvents is currently not well maintained or well tested. Patches will generally +get merged *if* there's a decent signal they're correct. Merely "it compiles" it +not enough, because so much of this relies on runtime behaviour. Either a new +test should be added, or patches should be tested manually. + +Really quick FSEvents overview +============================== +For those new to FSEvents itself (the Apple technology), here's a really quick +primer: + +Introduced in macOS v10.5, File System Events is made up of three parts: + +- kernel code that passes raw event data to user space through a special device +- a daemon that filters this stream and sends notifications +- a database that stores a record of all changes + +The API provides access to this system allowing applications to be notified of +changes to directory hierarchies, and also to retrieve a history of changes. +File System Events are path / file name based, *not* file descriptor based. This +means that if you watch a directory (path) and it is moved elsewhere your watch +does not automatically move with it. + +The API uses the concept of a *Stream* (FSEventStream) which is a configurable +stream of notifications. A Stream can recursively monitor many directories. +Options like latency which allow the coalescing of events are specific to one +stream. + +Persistent Monitoring +--------------------- +The database kept by the File System Events API allow a program that is run +periodically to check for changes to the file system between runs. This has a +real impact on the API and why there are parameters like `since`. This feature +should be considered *advisory* according to Apple's docs - a full scan should +still be run periodically. If an older version of macOS modifies the file system +(say, by removing the drive and putting it in another computer) it would not +update the database. + +The `since` parameter must be an EventID for the host or device that the stream +is for (or the special ALL or NOW values). + +To discover the EventID at a specific time the function `LastEventBefore` can be +used (calls `FSEventsGetLastEventIdForDeviceBeforeTime`); provide dev==0 for a +host EventID. Current() (calls FSEventsGetCurrentEventId) returns the most +recent EventID. + +Apple Docs +---------- +- [FSEvents_ProgGuide.pdf](https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/FSEvents_ProgGuide/FSEvents_ProgGuide.pdf) +- [FSEvents_ProgGuide html](https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005289-CH1-SW1) + +Device Streams vs Host Streams +------------------------------ +A Host Stream (dev == 0) can monitor directories through the entire system +(assuming appropriate permissions). EventIDs increase across all devices (i.e. +an older event on any device has a smaller EventID than a newer one except when +EventID's rollover). This means that if another disk is added / mounted then +there is the potential for a historical EventID conflict. + +A Device Stream (pass a `Device` to `New`) can monitor directories only on the +given device. Because the EventIDs refer only to that device there is no chance +of conflict. + +For real-time monitoring there aren't any notable advantages to a Device Stream +over a Host stream. For persistent monitoring (run a program today to see what +changed yesterday) Device Streams are more robust since there can be no EventID +conflict. + +File Events +----------- +Is macOS v10.7 Apple introduced *File Events* +(kFSEventStreamCreateFlagFileEvents aka CF_FILEEVENTS). Prior to this events are +delivered for directories only, i.e. if /tmp/subdir/testfile is modified and an +FSEventStream is monitoring /tmp then an event would be delivered for the path +/tmp/subdir. This tells the application that it should scan /tmp/subdir for +changes. It was also possible (in corner cases) that an event for the path /tmp +could be created with MUSTSCANSUBDIRS set. This should only happen if events are +being dropped, and had to be coalesced to prevent the loss of information. + +With CF_FILEEVENTS set (>= macOS v10.7) events are generated with the path +specifying the individual files that have been modified. I haven't found +explicit mention, but it seems likely that the same caveats apply with respect +to coalescing if events are being dropped. + +Apple warns that using File Events will cause many more events to be generated +(in part, I expect, because they don't coalesce as easily as directory-level +events). + +Temporal Coalescing +------------------- +If two files in the same directory are changed in a short period of time (e.g. +/tmp/test1 and /tmp/test2) (assuming CF_FILEEVENTS=0) a single event could be +delivered to the application specifying that the path `/tmp` contains changes. +There is an efficiency boost when scanning /tmp only once looking for all +changes versus scanning it once for test1 and once for test2. The `latency` +parameter enables this kind of temporal coalescing. If `latency` is set to, say, +1 second then the application will not be notified more than once a second about +changes. The flag kFSEventStreamCreateFlagNoDefer aka CF_NODEFER specifies +whether the application is notified on the leading or lagging edge of changes. + +Structure of fsevents.go +======================== + +Creating a Stream +----------------- + +`EventStream` encapsulates an FSEventStream, and allows an arbitrary number of +paths to be monitored. + +For real-time monitoring an EventStream is created with `Resume` == `false`. +This means it will not deliver historical events. If `Resume` == `true` then all +recorded events for the supplied paths since `EventId` would be supplied first, +then realtime events would be supplied as they occur. + +The `Latency` parameter is passed on to the API, and used to throttle / coalesce +events - '0' means deliver all events. + +`Device` can be used to create streams specific to a device, (See Device Streams +vs Host Streams). Use '0' to create a host stream. + +Instantiating an `EventStream` just allocates memory to store the +*configuration* of the stream. Calling `EventStream.Start` creates the +FSEventStream, and a channel that will be used to report events +`EventStream.Events` (unless one has already been supplied). The EventStream is +stored (via an unsafe.Pointer) in the FSEventStream context (so the OS callback +has access to it). + +Running a Stream +---------------- + +In macOS an application must run a RunLoop (see: [Run Loop +Management][https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html#//apple_ref/doc/uid/10000057i-CH16-SW1]) +for each thread that wishes to receive events from the operating system. + +An FSEventStream needs to be started, and must be supplied with a Runloop +reference to deliver events to. + +To accomplish this `EventStream.Start` creates a goroutine that calls +CFRunLoopRun(). The call in to CFRunLoopRun does not return until the runloop is +stopped by `EventStream.Stop`. I _believe_ that the current implementation will +work correctly because of the following: + +- There is a many->one mapping from goroutines to os threads (i.e. goroutines do + not switch os-threads). + +- The os thread that runs the Run Loop will not be available for other + goroutines because CFRunLoopRun does not return. + +- This therefore means that each call to `EventStream.Start` will consume an OS + thread until the runloop is stopped by `EventStream.Stop` calling + CFRunLoopStop. Each Stream will get it's own Run Loop (on it's own OS thread). -## Contributing +Receiving Events +---------------- +The File System Events API causes a C-callback to be called by delivering an +event. The callback extracts / converts the supplied data then posts an array of +`Event`s on the channel `EventStream.Events`. The `EventStream` is stored in the +context parameter of the FSEventStream (supplied back to the callback by the +File System Events API). -Request features and report bugs using the [GitHub Issue Tracker](https://github.com/fsnotify/fsevents/issues). +Stopping a Stream +----------------- +`EventStream.Stop` stops and invalidates the stream (as per the File System +Events API requirements), then releases the Stream memory, and stops the runloop +that was started by `EventStream.Start`. This returns the `EventStream` to +(almost) the same state as before `EventStream.Start` was called. The difference +is that `EventStream.EventID` is now set to the last event ID received before +the stream was stopped, and `EventStream.Events` will now reference an +instantiated channel (it may have been nil before the call to +`EventStream.Start`). -fsevents carries the same [LICENSE](https://github.com/fsnotify/fsevents/blob/master/LICENSE) as Go. Contributors retain their copyright, so you need to fill out a short form before we can accept your contribution: [Google Individual Contributor License Agreement](https://developers.google.com/open-source/cla/individual). +Memory / Callback Safety +------------------------ +`EventStream` manages some OS resources (an OS thread, an FSEventStream, an OS +runloop, etc). If the `EventStream` is garbage collected without the being +stopped then a panic is likely. This is caused by an FSEventStream callback +attempting to reference the `EventStream` via an `unsafe.Pointer`. To guard +against this situation a finalizer is attached to the `EventStream` when it is +started. When the finalizer triggers (through GC of the `EventStream`) it stops +the stream so that the OS resources can be freed. This prevents the panic. diff --git a/example/main.go b/example/main.go index cf56c06..fc3c332 100644 --- a/example/main.go +++ b/example/main.go @@ -1,11 +1,9 @@ //go:build darwin -// +build darwin package main import ( "bufio" - "io/ioutil" "log" "os" "runtime" @@ -15,9 +13,9 @@ import ( ) func main() { - path, err := ioutil.TempDir("", "fsexample") + path, err := os.MkdirTemp("", "fsexample") if err != nil { - log.Fatalf("Failed to create TempDir: %v", err) + log.Fatalf("Failed to create MkdirTemp: %v", err) } dev, err := fsevents.DeviceForPath(path) if err != nil { diff --git a/fsevents.go b/fsevents.go index b3430aa..72ea28c 100644 --- a/fsevents.go +++ b/fsevents.go @@ -1,5 +1,4 @@ //go:build darwin -// +build darwin // Package fsevents provides file system notifications on macOS. package fsevents @@ -16,7 +15,7 @@ type Event struct { // to its device's root. // Use DeviceForPath to determine the absolute path that's // being referred to. - Path string + Path string // Flags holds details what has happened. Flags EventFlags @@ -33,7 +32,7 @@ type Event struct { // and resume processing them later from a newly-created // EventStream, this is the value you would pass for the // EventStream.EventID along with Resume=true. - ID uint64 + ID uint64 } // DeviceForPath returns the device ID for the specified volume. @@ -49,10 +48,10 @@ func DeviceForPath(path string) (int32, error) { // You can provide your own event channel if you wish (or one will be // created on Start). // -// es := &EventStream{Paths: []string{"/tmp"}, Flags: 0} -// es.Start() -// es.Stop() -// ... +// es := &EventStream{Paths: []string{"/tmp"}, Flags: 0} +// es.Start() +// es.Stop() +// ... type EventStream struct { stream fsEventStreamRef rlref cfRunLoopRef @@ -62,19 +61,19 @@ type EventStream struct { // Events holds the channel on which events will be sent. // It's initialized by EventStream.Start if nil. - Events chan []Event + Events chan []Event // Paths holds the set of paths to watch, each // specifying the root of a filesystem hierarchy to be // watched for modifications. - Paths []string + Paths []string // Flags specifies what events to receive on the stream. - Flags CreateFlags + Flags CreateFlags // Resume specifies that watching should resume from the event // specified by EventID. - Resume bool + Resume bool // EventID holds the most recent event ID. // diff --git a/fsevents_test.go b/fsevents_test.go index 3f7bc6e..1bcfc30 100644 --- a/fsevents_test.go +++ b/fsevents_test.go @@ -1,11 +1,9 @@ //go:build darwin -// +build darwin package fsevents import ( "fmt" - "io/ioutil" "os" "path/filepath" "testing" @@ -13,7 +11,7 @@ import ( ) func TestBasicExample(t *testing.T) { - path, err := ioutil.TempDir("", "fsexample") + path, err := os.MkdirTemp("", "fsexample") if err != nil { t.Fatal(err) } @@ -52,7 +50,7 @@ func TestBasicExample(t *testing.T) { } }() - err = ioutil.WriteFile(filepath.Join(path, "example.txt"), []byte("example"), 0700) + err = os.WriteFile(filepath.Join(path, "example.txt"), []byte("example"), 0700) if err != nil { t.Fatal(err) } @@ -67,7 +65,7 @@ func TestIssue48(t *testing.T) { // FSEvents fails to start when watching >4096 paths // This test validates that limit and checks that the error is propagated - path, err := ioutil.TempDir("", "fsmanyfiles") + path, err := os.MkdirTemp("", "fsmanyfiles") if err != nil { t.Fatal(err) } @@ -86,7 +84,7 @@ func TestIssue48(t *testing.T) { var filenames []string for i := 0; i < 4096; i++ { newFilename := filepath.Join(path, fmt.Sprint("test", i)) - err = ioutil.WriteFile(newFilename, []byte("test"), 0700) + err = os.WriteFile(newFilename, []byte("test"), 0700) if err != nil { t.Fatal(err) } @@ -118,7 +116,7 @@ func TestIssue48(t *testing.T) { }() // write some new contents to test42 in the watchlist - err = ioutil.WriteFile(filenames[42], []byte("special"), 0700) + err = os.WriteFile(filenames[42], []byte("special"), 0700) if err != nil { t.Fatal(err) } @@ -129,7 +127,7 @@ func TestIssue48(t *testing.T) { ///// // create one more file that puts it over the edge newFilename := filepath.Join(path, fmt.Sprint("test", 4096)) - err = ioutil.WriteFile(newFilename, []byte("test"), 0700) + err = os.WriteFile(newFilename, []byte("test"), 0700) if err != nil { t.Fatal(err) } @@ -143,9 +141,9 @@ func TestIssue48(t *testing.T) { Flags: FileEvents, } - err = es.Start() + err = es2.Start() if err == nil { - es.Stop() + es2.Stop() t.Fatal("eventstream error was not detected on >4096 files in watchlist") } } diff --git a/go.mod b/go.mod index 13a09df..129225d 100644 --- a/go.mod +++ b/go.mod @@ -1,3 +1,3 @@ -go 1.16 +go 1.17 module github.com/fsnotify/fsevents diff --git a/wrap.go b/wrap.go index 29629a4..6b8fe60 100644 --- a/wrap.go +++ b/wrap.go @@ -1,5 +1,4 @@ //go:build darwin -// +build darwin package fsevents diff --git a/wrap_test.go b/wrap_test.go index 8c743aa..3ee78e3 100644 --- a/wrap_test.go +++ b/wrap_test.go @@ -1,5 +1,4 @@ //go:build darwin -// +build darwin package fsevents