Skip to content

Conversation

@arp242
Copy link
Member

@arp242 arp242 commented Oct 16, 2022

Use CircleCI to add CI for this.

Fixes #136

Use CircleCI to add CI for this.
@arp242 arp242 force-pushed the circleci-project-setup branch 3 times, most recently from d1e05fc to acf35b3 Compare October 17, 2022 00:20
@arp242 arp242 force-pushed the circleci-project-setup branch 2 times, most recently from ff7fe97 to 1aacce1 Compare October 17, 2022 01:34
Provide full API compatibility on unsupported systems such as AIX.
@arp242 arp242 force-pushed the circleci-project-setup branch from 1aacce1 to 7375fe9 Compare October 17, 2022 01:35
@arp242 arp242 merged commit 666d503 into main Oct 17, 2022
@arp242 arp242 deleted the circleci-project-setup branch October 17, 2022 01:57
@sagikazarmark
Copy link

Do you have an ETA for the next release? This PR in particular would help remove some wrapper code around fsnotify from Viper to let it build on unsupported platforms.

@arp242
Copy link
Member Author

arp242 commented Nov 3, 2022

Do you have an ETA for the next release? This PR in particular would help remove some wrapper code around fsnotify from Viper to let it build on unsupported platforms.

Not really; something on the order of months.

If the wrapper code already exists and works, then I don't think we really need to rush out a release?

@arp242
Copy link
Member Author

arp242 commented Nov 3, 2022

Also, looking at the workaround, it seems you added it in 2021 @sagikazarmark over here: https://github.com/spf13/viper/blob/master/watch_wasm.go

Don't be afraid to report these kind of things upstream (i.e. here); the fix is trivial, and it almost certainly would have been in the v1.6.0 release ... if I had known about it. I just happened to stumble on it in this PR, which is why it's fixed here.

Doing a release now with just some minor bugfixes just creates a lot of churn for everyone IMO. The workaround doesn't seem so bad to keep for the time being.

@sagikazarmark
Copy link

No rush on removing the wrapper now. Just wanted to know if a release would happen in the near future. I would have kept the relevant PR open.

TBH I completely forgot about it. The only reason it came to my attention is because someone asked for adding AIX to the list in addition to JS.

Thanks for all the work you are doing on fsnotify!

@shogo82148 shogo82148 mentioned this pull request Mar 6, 2024
25 tasks
belimawr added a commit to belimawr/fsnotify that referenced this pull request Sep 25, 2024
Release 1.7.0

This version of fsnotify needs Go 1.17.

Additions:

- illumos: add FEN backend to support illumos and Solaris. ([fsnotify#371])

- all: add `NewBufferedWatcher()` to use a buffered channel, which can
  be useful in cases where you can't control the kernel buffer and
  receive a large number of events in bursts. ([fsnotify#550], [fsnotify#572])

- all: add `AddWith()`, which is identical to `Add()` but allows passing
  options. ([fsnotify#521])

- windows: allow setting the ReadDirectoryChangesW() buffer size with
  `fsnotify.WithBufferSize()`; the default of 64K is the highest value
  that works on all platforms and is enough for most purposes, but in
  some cases a highest buffer is needed. ([fsnotify#521])

Changes and fixes:

- inotify: remove watcher if a watched path is renamed ([fsnotify#518])

  After a rename the reported name wasn't updated, or even an empty
  string. Inotify doesn't provide any good facilities to update it, so
  just remove the watcher. This is already how it worked on kqueue and
  FEN.

  On Windows this does work, and remains working.

- windows: don't listen for file attribute changes ([fsnotify#520])

  File attribute changes are sent as `FILE_ACTION_MODIFIED` by the
  Windows API, with no way to see if they're a file write or attribute
  change, so would show up as a fsnotify.Write event. This is never
  useful, and could result in many spurious Write events.

- windows: return `ErrEventOverflow` if the buffer is full ([fsnotify#525])

  Before it would merely return "short read", making it hard to detect
  this error.

- kqueue: make sure events for all files are delivered properly when
  removing a watched directory ([fsnotify#526])

  Previously they would get sent with `""` (empty string) or `"."` as
  the path name.

- kqueue: don't emit spurious Create events for symbolic links ([fsnotify#524])

  The link would get resolved but kqueue would "forget" it already saw
  the link itself, resulting on a Create for every Write event for the
  directory.

- all: return `ErrClosed` on `Add()` when the watcher is closed ([fsnotify#516])

- other: add `Watcher.Errors` and `Watcher.Events` to the no-op
  `Watcher` in `backend_other.go`, making it easier to use on
  unsupported platforms such as WASM, AIX, etc. ([fsnotify#528])

- other: use the `backend_other.go` no-op if the `appengine` build tag
  is set; Google AppEngine forbids usage of the unsafe package so the
  inotify backend won't compile there.

[fsnotify#371]: fsnotify#371
[fsnotify#516]: fsnotify#516
[fsnotify#518]: fsnotify#518
[fsnotify#520]: fsnotify#520
[fsnotify#521]: fsnotify#521
[fsnotify#524]: fsnotify#524
[fsnotify#525]: fsnotify#525
[fsnotify#526]: fsnotify#526
[fsnotify#528]: fsnotify#528
[fsnotify#537]: fsnotify#537
[fsnotify#550]: fsnotify#550
[fsnotify#572]: fsnotify#572
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Builders for continuous integration

3 participants