os/fsnotify: add new package

[rsc]

Issue for creating standard fsnotify package (current exp/inotify)

[gopherbot]

Comment 1 by howeyc:

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.

[alberts]

Comment 2:

exp/inotify has some open issues: issue #2483, issue #3132

[gopherbot]

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?

[gopherbot]

Comment 4 by jnwhiteh:

There are still data races in fsnotify, in particular between addWatch and the
readEvents goroutine simultaneously accessing the map.
This same race has been fixed in exp/inotify, but I don't see the corresponding fix in
fsnotify.

[rsc]

Comment 5:

Labels changed: added go1.1.

[gopherbot]

Comment 6 by cpisto:

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.

[gopherbot]

Comment 7 by peter.waller:

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

[gopherbot]

Comment 8 by howeyc:

@ 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.

[gopherbot]

Comment 9 by cpisto:

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.

[gopherbot]

Comment 10 by howeyc:

I agree, the API probably does need some work to provide something similar to
os.FileInfo.Sys() so that access is there if you really want it.

[gopherbot]

Comment 11 by aaron.l.france:

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

[minux]

Comment 12:

i don't understand why adding this package to the standard library adds that much
complexity?
if i read correctly, you mean the smaller the standard library the better?
or the proposed new package isn't consistent with the other standard packages?

[gopherbot]

Comment 13 by aaron.l.france:

My point was that it's prudent to be extra sure this is required when adding it. Once
added there's little chance of removing it.

[nathany]

Comment 14:

What I like about including fsevents, etc. in the stdlib is that it opens up
possibilities to use it from within. One example would be to have built in
autotest/guard (Ruby) or SBT (Scala) like functionality built into the go (test) tool.

[rsc]

Comment 15:

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.