Sync with main #4
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- macos-12 runner no longer exists, so use macos-13. - We switched to Linux/QEMU based runners some time ago, so less likely to run in to GitHub limits on macOS runners, meaning we have some room to test Go 1.17 on macOS now. - Update Cirrus CI FreeBSD image. - Run linux/arm64 on GitHub Actions, as that's now supported. - Remove iOS on CircleCI; I don't think that really adds much beyond macOS, and dealing with different CI systems is annoying. - Update latest Go version to 1.24
Ignore some fs.ErrNotExist errors in locations where it's safe to do so. This is what all other backends do. Also add some more details to the errors; just "no such file or directory" is not very helpful.
It's a long-standing problem that some tests intermittently fail on the CI with this, but with the new TestRace/remove_self it would be fairly consistently reproducible. Seems what would happen is that it did "fd := w.path[path]", and that this could return 0 as that path had already been removed. That would close fd 0 (stdin), fd 0 then got re-used for the next test, which would work for a bit until it didn't and you got an error. Also ignore some ErrNotExist errors. This doesn't completely fix it; it still fails on occasion. I want to rewrite the kqueue backend anyway, and it's been a problem for as long as I've been involved. So not a priority to completely fix it right now.
inotify_add_watch() follows symlinks, and returns the current watch descriptor when adding a patch twice. So when doing "watch dir" and "watch link" (or reverse) second watch is basically a no-op; yet it's still registered as a "separate" watch, and would panic on removing the second. The solution is to make the second Add() a no-op. This is also what kqueue does, and what happens if you watch the same path twice. On illumos watching a symlink currently means registering double watches; this is a separate bug that should be fixed. Fixes #652 Fixes #662
The size parameter didn't actually get passed to the make() call; regression from #632. Also make sure the default buffer size is 50 on Windows again. There is no need for a separate newBackend() and newBufferedBackend() in the first place, as the buffer size just controls the channel buffer size which is now done in the generic fsnotify.go, so refactor to remove that. Signed-off-by: Bryan Boreham <[email protected]>
Also only resolve symlinks explicitly given in Add()/AddWith(), and not those added "internally" as part of a listdir. Also don't ignore errors from os.Readlink() and os.Lstat; this was added in 2012 with bf36090 to ignore unresolvable symlinks when listing a directory, but we're no longer calling lstat() on the result of a link unless it's explicitly passed with Add(). Fixes #661
Events we get from inotify: FSNOTIFY_DEBUG: 13:18:09.748020414 IN_ISDIR|IN_UNMOUNT → "mnt/dir" FSNOTIFY_DEBUG: 13:18:09.748051964 IN_IGNORED → "mnt/dir" The IN_UNMOUNT wouldn't map to anything, so it would send an empty event. Fixes #655
…kqueue It would mark /dir/existing as seen, but would check for /link/existing. So on the first change in a directory it would list all pre-existing entries in the directory. Regression from d2ee00e; just wasn't a testcase.
Normally tests take 3 to 4 minutes at the most, for the tests that use a QEMU VM. But sometimes either a test or booting the VM will hang. Fail faster on this.
It's all the same code now (wasn't historically). Only Windows is still different, so don't do it for that.
Change locking to be less fine-grained: just lock the watcher while we're processing an event, so we're operating on a consistent "snapshot". This is basically how it worked before 16df002. Moving some of bookkeeping to a separate "helper struct" was a good idea; doing the locking in that struct wasn't.
I've tried to ping/contact the AIX people a few times over the last few years, and I never got a reply. So I deleted the branch a while ago. Supporting some proprietary OS where the developers can't even be bothered to acknowledge my existence is not on.
Looks like it wasn't really being run? Guess I didn't use that -matrix correctly? Just use a simple shell script. Also run go vet, and remove the build workflow: that's redundant now.
Taken from a branch I worked on some time ago where this was a bug. Also clarify that WatchList() order is undefined.
Sometimes useful when debugging things. Also reduce the kqueue debug flags to just the EVFILT_VNODE ones.
This way we can use type parameters (I want to in another branch), and we can remove the rlimit stuff as that's in Go 1.19 now.
Enabled this recently, but gccgo doesn't support generics so remove it again. Looking at [1], it seems gccgo is not especially actively developed. Maybe there is some other work somewhere? I don't know. We don't *need* to use generics now, but it does make things just a tad nicer, and I'm not too keen on being "held back" by gccgo, which sees very little real usage AFAIK. [1]: https://gcc.gnu.org/git/?p=gcc.git;a=history;f=libgo;hb=HEAD
20.04 was removed.
This mimics what happens with a non-recursive watch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mainly interested in these:
inotify: fix race when adding/removing watches while a watched path is being
deleted ([Fix race in inotify backend fsnotify/fsnotify#678], [Simplify inotify backend locking fsnotify/fsnotify#686])
inotify: don't send empty event if a watched path is unmounted ([Undocumented "no events" Op on Linux when a watched directory is unmounted fsnotify/fsnotify#655])
inotify: don't register duplicate watches when watching both a symlink and its
target; previously that would get "half-added" and removing the second would
panic ([Don't add double watches for symlinks fsnotify/fsnotify#679])