os/fsnotify: add new package #4068
Labels
Milestone
Comments
I created a library that does this and tried to be as consistent between operating systems as I could. It works on OSX/BSD/Linux/Windows. I could attempt to merge it in, or someone more familiar with your contributing process could do so with my blessing. Take a look: https://github.com/howeyc/fsnotify Generated GoDoc: http://go.pkgdoc.org/github.com/howeyc/fsnotify I'll follow this issue to get your feedback. |
exp/inotify has some open issues: issue #2483, issue #3132 |
|
Comment 3 by uriel@berlinblue.org: Quite a few people are using howeyc's fsnotify package quite successfully, the API might need a bit of tuning, but seems to be relatively close to exp/inotify. Any advice on what would be the best approach to merge fsnotify into mainline? |
While I like the idea of fsnotify, it seems to me a more idiomatic go approach would be to design a file system event interface (FileWatcher?) around the existing inotify & winfsnotify exp packages (in addition to some future kevent based package for the bsds). fsnotify as it stands now hides much of the detail provided by the underlying interfaces and definitely has some oddities in its current implementation. For instance it seems to register to receive all event types it supports with the underlying OS backend regardless of the event mask specified by the user. |
In addition to the above comment, fsnotify does not allow detecting when a file is modified due to a rename. This means you can't see configuration files modified by many types of text editor which use the atomicity of a rename to wholly update the file on save. This seems like one of the primary use cases of fsnotify for which it unfortunately doesn't currently work. howeyc/fsnotify#15 |
@ Comment 6 What you have to remember is that go hides some of the underlying interfaces for consistency as well. The net package for example, you don't write apps that do epoll on linux, kevent/kqueue on OSX/BSD and winsock on Windows, you write against net. I concede my interface may not be optimal, I just went with whatever exp/inotify was doing, but providing every available os-specific mask for each OS does not exactly encourage portability. The goal I had in mind is that you could write against fsnotify on linux, copy your source tree to windows, build and not have to change anything. In order to do that I did have to impose some limitations to attempt consistency across operating systems. |
Fully understood, go hides things when it makes sense. In certain cases, it still offers access to underlying OS specific features in the interests of being a useful system programming language (look at os.FileInfo.Sys() for example). Filesystem event notification looks to present enough cross platform differences to warrant some exploration in that direction. Don't get me wrong, fsnotify is great stuff, I just think inclusion of it or something like it could use a little back and forth :) At the minimum, refactoring it to only register with the underlying APIs for the user requested event mask instead of all supported events, and cleaning up the various data races that have been fixed or identified in the exp inotify/winfsnotify packages seems prudent. |
Is this something that really needs to be in the standard library? It doesn't really seem to gel with the rest of the standard library packages, to me. I'm not trying to poo-poo it or anything, it seems like it would be quite useful. However, in the interests of fighting complexity it would seem like a bit of a sore thumb in the standard library. As a sort of side-point to this, why isn't there a "contrib" set of packages? It seems like this would be perfect for a quasi-sanctioned contrib package. Just my $0.02. I know that one of the biggest draws for me to Go is it's incredibly consistent standard library, having yet more packages worries me about increasing entropy. Regards, Aaron |
I regret dropping the ball on this, but we won't have time to get this into Go 1.1. I replied on howeyc's CL thread. I'd gladly accept a CL putting this in the go.exp subrepo so that we can get more experience using it. Re #12, one source of complexity is that it's not uniformly supported on all systems. Labels changed: removed go1.1. |
Just an update... there are currently 56 packages the import fsnotify on GitHub and an additional 7 importing the mirror at go.exp. We are starting on an FSEvents adapter for OS X which is more efficient at watching large directory structures than kqueue. FSEvents provides two options that are frequently requested by fsnotify users: 1. It does recursive watches on a directory structure, which isn't unique, but apparently it doesn't have a non-recursive option. 2. It can coalesce events within a given latency, such as when an editor saves a file twice. The fsnotify API is becoming even more high-level to offer consistent behaviour across OSes. We currently have a git branch (pull request) that replaces the previous event mask filtering (FSN_CREATE, etc.) with a more general purpose event processing pipeline. The idea being that if an adapter (eg. inotify) doesn't support a given option, we will perform our own filtering on the incoming events. It's certainly going to take some time to for all this to come together and to settle on a good high-level API. As far as a low-level APIs, I suspect the ideal situation will be to have packages for inotify, kqueue, winfsnotify, and fsevents at the "syscall" level that are implemented in such a way that os.fsnotify can build on top of them. Having spent some time in the fsnotify code, I suspect that getting to this state will be quite an undertaking! Feel free to join in on the fun. :-) P.S. Aaron, is https://github.com/golang the new contrib? |
The API document is at http://goo.gl/MrYxyA. |
FYI, the equivalent issue in the fsnotify issue tracker is: go-fsnotify/fsnotify#1 |
|
Just in case someone lands here from the search there's also another library with API similar to |
|
Well ! It's a good new because only two libraries work but each has specific running (recursive or not…). Make a « official » lib is good to unify the golang environment. +1 |
|
At this point I don't know if it makes sense to have os/fsnotify in the standard library. Maybe an x/fsnotify package to benefit from Gerrit, the cross-platform builders, and the CLA process. That would also make it more official, but without have a compatibility promise. Whether that's based on the current revision of fsnotify or @rjeczalik's library, I'm not sure. I've been meaning to take a closer look at notify. |
|
At this point, and in light of burnout among the core team, I think this issue can be safely closed. Please correct me if I'm wrong.
If anyone reading this has the bandwidth and interest in file system notifications, you are certainly welcome to contribute as much or little as you like over at https://github.com/fsnotify. Thanks. |
|
Closing this, as requested. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: