code review 5585043: exp/fsnotify: Cross-platform filesystem notifications

exp/fsnotify: Cross-platform filesystem notifications

This package mimics the current exp/inotify for the linux platform
as much as possible. Anyone using exp/inotify should be able to
switch. This simply adds a similar interface for BSD systems.

The same test is used regardless of OS.

[howeyc, 2012-01-27 15:02:01]

Hello golang-dev@googlegroups.com, robfig@gmail.com, dave@cheney.net (cc:
bradfitz@golang.org, golang-dev@googlegroups.com, rsc@golang.org),

I'd like you to review this change to
https://go.googlecode.com/hg/

[rsc, 2012-01-27 16:41:49]

Hi,

Thanks very much for sending this in.  We're working on
making the code base as solid as possible for Go 1, meaning
fixing bugs and letting things settle.  Even though this code
is in exp/ and wouldn't affect Go 1 directly, we need to focus
our available time on getting Go 1 out the door.  Please remind
us about this CL once Go 1 is done, and we will review it then.
I definitely want to see a portable package for this kind of thing,
so I'm interested to see this get in, just after Go 1.

Thanks.
Russ

[robfig, 2012-02-12 16:20:01]

On 2012/01/27 15:02:01, howeyc wrote:
> Hello mailto:golang-dev@googlegroups.com, mailto:robfig@gmail.com,
mailto:dave@cheney.net (cc:
> mailto:bradfitz@golang.org, mailto:golang-dev@googlegroups.com,
mailto:rsc@golang.org),
> 
> I'd like you to review this change to
> https://go.googlecode.com/hg/

Hey Howey,

I'm trying it out on OSX, and I have some questions about the behavior: 

1. The first time something changes in a watched directory, I get a "CREATE"
event for every file in the watched directories.  It looks like this happens
because calling Watch(path) watches the directory, but an event ends up calling
sendDirectoryChangeEvents which checks for / adds watches on all of the files in
the directories, sending CREATE events if the watches were not there.  I assume
this is not expected behavior? 

2. I don't think it's necessary to watch the files themselves.  It looks like
the events you are registering on the files (DELETE/RENAME/WRITE) would all be
generated by watches on the directories, since they cause changes to the
directory entry as well.  (In practice, watching only the directory has worked
for me, although I did not exhaustively test it).  Did you find a use case that
didn't work with only the directory watch?

Thanks,
Rob

[howeyc, 2012-02-13 17:36:19]

Rob,

Thank you for trying this on OSX.


> Hey Howey,
>
> I'm trying it out on OSX, and I have some questions about the behavior:
>
> 1. The first time something changes in a watched directory, I get a
> "CREATE" event for every file in the watched directories.  It looks like
> this happens because calling Watch(path) watches the directory, but an
> event ends up calling sendDirectoryChangeEvents which checks for / adds
> watches on all of the files in the directories, sending CREATE events if
> the watches were not there.  I assume this is not expected behavior?
>

The call of sendDirectoryChangeEvents is something I added to mimic the
behavior I found on the Linux inotify API. In Linux, simply watching a
directory will also give you events for files in the directory as well. The
kqueue interface on BSD only tells you the directory changed, it's up to
the user land application to figure out what new files are there (if any).

You may be correct about getting CREATE events for every existing file
being unintended behavior. I will have to review what inotify does in the
case of files already existing when the watch is added.


>
> 2. I don't think it's necessary to watch the files themselves.  It looks
> like the events you are registering on the files (DELETE/RENAME/WRITE)
> would all be generated by watches on the directories, since they cause
> changes to the directory entry as well.  (In practice, watching only the
> directory has worked for me, although I did not exhaustively test it).
> Did you find a use case that didn't work with only the directory watch?
>

If you're talking about watching only directories using this exp/fsnotify
patch, then yes, you should be okay only watching directories. However, in
order for that to work, the go library must "watch" each file using
kqueue/kevent BSD system calls.

Cheers,
Chris

[howeyc, 2012-03-29 01:40:52]

On 13 February 2012 11:36, Chris Howey <howeyc@gmail.com> wrote:

> Rob,
>
> Thank you for trying this on OSX.
>
>
>> Hey Howey,
>>
>> I'm trying it out on OSX, and I have some questions about the behavior:
>>
>> 1. The first time something changes in a watched directory, I get a
>> "CREATE" event for every file in the watched directories.  It looks like
>> this happens because calling Watch(path) watches the directory, but an
>> event ends up calling sendDirectoryChangeEvents which checks for / adds
>> watches on all of the files in the directories, sending CREATE events if
>> the watches were not there.  I assume this is not expected behavior?
>>
>
> The call of sendDirectoryChangeEvents is something I added to mimic the
> behavior I found on the Linux inotify API. In Linux, simply watching a
> directory will also give you events for files in the directory as well. The
> kqueue interface on BSD only tells you the directory changed, it's up to
> the user land application to figure out what new files are there (if any).
>
> You may be correct about getting CREATE events for every existing file
> being unintended behavior. I will have to review what inotify does in the
> case of files already existing when the watch is added.
>
>
>>
>> 2. I don't think it's necessary to watch the files themselves.  It looks
>> like the events you are registering on the files (DELETE/RENAME/WRITE)
>> would all be generated by watches on the directories, since they cause
>> changes to the directory entry as well.  (In practice, watching only the
>> directory has worked for me, although I did not exhaustively test it).
>> Did you find a use case that didn't work with only the directory watch?
>>
>
> If you're talking about watching only directories using this exp/fsnotify
> patch, then yes, you should be okay only watching directories. However, in
> order for that to work, the go library must "watch" each file using
> kqueue/kevent BSD system calls.
>
> Cheers,
> Chris
>
>
To all that are interested, I have "merged" the code from exp/winfsnotify
into the library. I'm a little fuzzy on how the windows file system
notification API works, such as no attribute notification (test fails), so
if anyone has any insight (I've included hector as he was the original
author I believe) I'd like to hear your thoughts.

I've placed the code up on github so we can review and make changes before
putting it through the formal review process. If you'd rather we keep
modifying this changeset (or create another) I am more than happy to do
that, for now It's up on github if anyone would like to assist.

https://github.com/howeyc/fsnotify.go

Thanks!
Chris

[dave_cheney.net, 2012-03-29 01:58:54]

Fantastic. I look forward to playing with it this evening. 

On 29/03/2012, at 12:40, Chris Howey <howeyc@gmail.com> wrote:

> On 13 February 2012 11:36, Chris Howey <howeyc@gmail.com> wrote:
> Rob,
> 
> Thank you for trying this on OSX.
> 
> 
> Hey Howey,
> 
> I'm trying it out on OSX, and I have some questions about the behavior:
> 
> 1. The first time something changes in a watched directory, I get a
> "CREATE" event for every file in the watched directories.  It looks like
> this happens because calling Watch(path) watches the directory, but an
> event ends up calling sendDirectoryChangeEvents which checks for / adds
> watches on all of the files in the directories, sending CREATE events if
> the watches were not there.  I assume this is not expected behavior?
> 
> The call of sendDirectoryChangeEvents is something I added to mimic the
behavior I found on the Linux inotify API. In Linux, simply watching a directory
will also give you events for files in the directory as well. The kqueue
interface on BSD only tells you the directory changed, it's up to the user land
application to figure out what new files are there (if any).
> 
> You may be correct about getting CREATE events for every existing file being
unintended behavior. I will have to review what inotify does in the case of
files already existing when the watch is added.
>  
> 
> 2. I don't think it's necessary to watch the files themselves.  It looks
> like the events you are registering on the files (DELETE/RENAME/WRITE)
> would all be generated by watches on the directories, since they cause
> changes to the directory entry as well.  (In practice, watching only the
> directory has worked for me, although I did not exhaustively test it).
> Did you find a use case that didn't work with only the directory watch?
> 
> If you're talking about watching only directories using this exp/fsnotify
patch, then yes, you should be okay only watching directories. However, in order
for that to work, the go library must "watch" each file using kqueue/kevent BSD
system calls.
> 
> Cheers,
> Chris
> 
> 
> To all that are interested, I have "merged" the code from exp/winfsnotify into
the library. I'm a little fuzzy on how the windows file system notification API
works, such as no attribute notification (test fails), so if anyone has any
insight (I've included hector as he was the original author I believe) I'd like
to hear your thoughts.
> 
> I've placed the code up on github so we can review and make changes before
putting it through the formal review process. If you'd rather we keep modifying
this changeset (or create another) I am more than happy to do that, for now It's
up on github if anyone would like to assist.
> 
> https://github.com/howeyc/fsnotify.go
> 
> Thanks!
> Chris

[mattn, 2012-03-29 09:39:50]

It need bits patch.

https://gist.github.com/2235432

And it seens test not passed on windows.

On 2012/03/29 01:40:52, howeyc wrote:
> On 13 February 2012 11:36, Chris Howey <mailto:howeyc@gmail.com> wrote:
> 
> > Rob,
> >
> > Thank you for trying this on OSX.
> >
> >
> >> Hey Howey,
> >>
> >> I'm trying it out on OSX, and I have some questions about the behavior:
> >>
> >> 1. The first time something changes in a watched directory, I get a
> >> "CREATE" event for every file in the watched directories.  It looks like
> >> this happens because calling Watch(path) watches the directory, but an
> >> event ends up calling sendDirectoryChangeEvents which checks for / adds
> >> watches on all of the files in the directories, sending CREATE events if
> >> the watches were not there.  I assume this is not expected behavior?
> >>
> >
> > The call of sendDirectoryChangeEvents is something I added to mimic the
> > behavior I found on the Linux inotify API. In Linux, simply watching a
> > directory will also give you events for files in the directory as well. The
> > kqueue interface on BSD only tells you the directory changed, it's up to
> > the user land application to figure out what new files are there (if any).
> >
> > You may be correct about getting CREATE events for every existing file
> > being unintended behavior. I will have to review what inotify does in the
> > case of files already existing when the watch is added.
> >
> >
> >>
> >> 2. I don't think it's necessary to watch the files themselves.  It looks
> >> like the events you are registering on the files (DELETE/RENAME/WRITE)
> >> would all be generated by watches on the directories, since they cause
> >> changes to the directory entry as well.  (In practice, watching only the
> >> directory has worked for me, although I did not exhaustively test it).
> >> Did you find a use case that didn't work with only the directory watch?
> >>
> >
> > If you're talking about watching only directories using this exp/fsnotify
> > patch, then yes, you should be okay only watching directories. However, in
> > order for that to work, the go library must "watch" each file using
> > kqueue/kevent BSD system calls.
> >
> > Cheers,
> > Chris
> >
> >
> To all that are interested, I have "merged" the code from exp/winfsnotify
> into the library. I'm a little fuzzy on how the windows file system
> notification API works, such as no attribute notification (test fails), so
> if anyone has any insight (I've included hector as he was the original
> author I believe) I'd like to hear your thoughts.
> 
> I've placed the code up on github so we can review and make changes before
> putting it through the formal review process. If you'd rather we keep
> modifying this changeset (or create another) I am more than happy to do
> that, for now It's up on github if anyone would like to assist.
> 
> https://github.com/howeyc/fsnotify.go
> 
> Thanks!
> Chris

[howeyc, 2012-03-29 16:12:12]

On 29 March 2012 04:39, <mattn.jp@gmail.com> wrote:

> It need bits patch.
>
> https://gist.github.com/**2235432 <https://gist.github.com/2235432>
>
> And it seens test not passed on windows.
>
>
I fixed the line and renamed the repository.

https://github.com/howeyc/fsnotify

I am aware of the failed test. This is a call for help from someone who
knows the windows file notification API to tell me if windows even has an
Attribute change notification, and if so, how to fix it.

Thanks,
Chris

[brainman, 2012-03-30 01:42:35]

On 2012/03/29 16:12:12, howeyc wrote:
> 
> ... This is a call for help from someone who
> knows the windows file notification API to tell me if windows even has an
> Attribute change notification, and if so, how to fix it.
> 

Do you know about src/pkg/exp/winfsnotify? It is all in there.

Alex

[howeyc, 2012-03-30 21:06:52]

On 29 March 2012 20:42, <alex.brainman@gmail.com> wrote:

> On 2012/03/29 16:12:12, howeyc wrote:
>
>  ... This is a call for help from someone who
>>
>> knows the windows file notification API to tell me if windows even has
>>
> an
>
>> Attribute change notification, and if so, how to fix it.
>>
>
>
> Do you know about src/pkg/exp/winfsnotify? It is all in there.
>
> Alex
>
>
http://codereview.appspot.com/**5585043/<http://codereview.appspot.com/5585043/>


I have done some further investigation and it appears to me that windows
does not support attributes as a separate notification.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364391(v=vs.85).aspx

Right now, I have the library send a FileEvent over a channel and FileEvent
supports the following functions:

IsCreate()
IsDelete()
IsModify()
IsAttribute() * NOT SUPPORTED ON WINDOWS *
IsRename()


My thoughts are to roll IsAttribute() into IsModify() (and remove
IsAttribute()) so the same functions are exported across all
platforms.


Comments, concerns, etc?


Thanks,

Chris

[dave_cheney.net, 2012-03-30 21:48:22]

Sounds reasonable, similar to the precedent set by the
os.FileInfo.Sys() escape hatch.

On Sat, Mar 31, 2012 at 8:06 AM, Chris Howey <howeyc@gmail.com> wrote:
> On 29 March 2012 20:42, <alex.brainman@gmail.com> wrote:
>>
>> On 2012/03/29 16:12:12, howeyc wrote:
>>
>>> ... This is a call for help from someone who
>>>
>>> knows the windows file notification API to tell me if windows even has
>>
>> an
>>>
>>> Attribute change notification, and if so, how to fix it.
>>
>>
>>
>> Do you know about src/pkg/exp/winfsnotify? It is all in there.
>>
>> Alex
>>
>> http://codereview.appspot.com/5585043/
>
>
> I have done some further investigation and it appears to me that windows
> does not support attributes as a separate notification.
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa364391(v=vs.85).aspx
>
> Right now, I have the library send a FileEvent over a channel and FileEvent
> supports the following functions:
>
> IsCreate()
> IsDelete()
> IsModify()
> IsAttribute() * NOT SUPPORTED ON WINDOWS *
> IsRename()
>
>
> My thoughts are to roll IsAttribute() into IsModify() (and remove
> IsAttribute()) so the same functions are exported across all platforms.
>
>
> Comments, concerns, etc?
>
>
> Thanks,
>
> Chris
>
>

[brainman, 2012-04-01 04:49:49]

On 2012/03/30 21:06:52, howeyc wrote:
> 
> I have done some further investigation and it appears to me that windows
> does not support attributes as a separate notification.
>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364391%28v=vs.85%29...

I am not even sure what do "attributes" mean in Windows. If you mean "who can
act on file" and "what can be done" to a file, then Windows files do have ACLs.
But Windows ACLs can't be inquired about as per current Go standard libraries.
So, I suppose, we should not worry about them. Yet.

> My thoughts are to roll IsAttribute() into IsModify() (and remove
> IsAttribute()) so the same functions are exported across all
> platforms.
> 

It is hard for me to advise, because I do not use this facility myself. But I
don't think, if you leave IsAttribute() (which will return false on windows) in,
it is a big deal.

> 
> Comments, concerns, etc?

I see no windows implementation in your proposal. What is your plan about that?
I thought, given that we have exp/winfsnotify package already, you should be
able to provide something that works. This way your design will be closer to
reality (I think "cross-platform" is the key word in your CL).

Alex

[howeyc, 2012-04-01 17:44:18]

On 31 March 2012 23:49, <alex.brainman@gmail.com> wrote:

> On 2012/03/30 21:06:52, howeyc wrote:
>
>  I have done some further investigation and it appears to me that
>>
> windows
>
>> does not support attributes as a separate notification.
>>
>
> http://msdn.microsoft.com/en-**us/library/windows/desktop/**
>
aa364391%28v=vs.85%29.aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/aa364391%28v=vs.85%29.aspx>
>
> I am not even sure what do "attributes" mean in Windows. If you mean
> "who can act on file" and "what can be done" to a file, then Windows
> files do have ACLs. But Windows ACLs can't be inquired about as per
> current Go standard libraries. So, I suppose, we should not worry about
> them. Yet.
>
> Sorry, I thought link was clear. Let me be more precise, from the link:

"FILE_ACTION_MODIFIED - The file was modified. This can be a change in the
time stamp or attributes."

This means the MODIFIED notification can be either file modification,
attribute notification, or both. This is not the case in BSD/Linux/OSX,
they are separate notifications on those OSs.

For example, on BSD:
http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&sektion=0&manpath=F...
Scroll down to the EVFILT_NODE section, notice how NOTE_WRITE and
NOTE_ATTRIB are separate.


>
>  My thoughts are to roll IsAttribute() into IsModify() (and remove
>> IsAttribute()) so the same functions are exported across all
>> platforms.
>>
>
>
> It is hard for me to advise, because I do not use this facility myself.
> But I don't think, if you leave IsAttribute() (which will return false
> on windows) in, it is a big deal.
>
>
I have decided to go the other route and remove IsAttribute() and have
other OSs return true for IsModify() in the case of an attribute change. I
don't like the idea of one OS having a function that always returns false
when all other OSs have the chance of getting a true.

However, if others would prefer an always-false function on windows in
return for more notification types on other OSs I have no problem doing
that.


>
>  Comments, concerns, etc?
>>
>
> I see no windows implementation in your proposal. What is your plan
> about that? I thought, given that we have exp/winfsnotify package
> already, you should be able to provide something that works. This way
> your design will be closer to reality (I think "cross-platform" is the
> key word in your CL).
>

This is the second time you have mentioned exp/winfsnotify. Let me assure
you once again, I do know it exists. It's what I merged into the fsnotify
library to provide windows support.

The fsnotify library behaves similar to inotify and winfsnotify in that it
sends Events over a channel. The difference is that instead of exposing the
mask, it provides four functions that can be called to determine the type
of notification:
IsCreate()
IsDelete()
IsModify()
IsRename()


Chris

[brainman, 2012-04-01 23:23:46]

On 2012/04/01 17:44:18, howeyc wrote:
> 
> ... I merged into the fsnotify
> library to provide windows support.
> 

Sorry, but I can't see it. Which of your changed files contains windows code?
Also, please update your CL to the tip. I can't download it. Probably, because
Makefiles have been deleted now. Thank you.

Alex

[howeyc, 2012-04-02 00:05:08]

On Apr 1, 2012 6:23 PM, <alex.brainman@gmail.com> wrote:
>
> On 2012/04/01 17:44:18, howeyc wrote:
>
>> ... I merged into the fsnotify
>>
>> library to provide windows support.
>
>
>
> Sorry, but I can't see it. Which of your changed files contains windows
> code? Also, please update your CL to the tip. I can't download it.
> Probably, because Makefiles have been deleted now. Thank you.
>
> Alex
>
> http://codereview.appspot.com/5585043/

Oh! I see the problem. I put the code on github while I tested various
platforms and got some feedback, I have not yet updated the changeset.

https://github.com/howeyc/fsnotify

Sorry for the confusion I caused!

Chris

[robfig, 2012-04-04 00:54:34]

Hi Chris,
I'm having one problem with it:
https://github.com/howeyc/fsnotify/blob/master/fsnotify_bsd.go#L187

On that line, you ignore the returned errno.  For some reason, when I start
up my server that configures and uses a watcher, the first Kevent call
always fails with "interrupted system call".  That may be specific to my
program (I'm not sure how to tell what it's doing to cause that -- any
suggestions?), but it also causes a panic when on the next line when it
indexes into the eventbuf slice.  Locally, I changed it to just continue if
there was an error, and things seem to work fine.

Thanks for doing this,
Rob


On Sun, Apr 1, 2012 at 8:05 PM, Chris Howey <howeyc@gmail.com> wrote:

>
> On Apr 1, 2012 6:23 PM, <alex.brainman@gmail.com> wrote:
> >
> > On 2012/04/01 17:44:18, howeyc wrote:
> >
> >> ... I merged into the fsnotify
> >>
> >> library to provide windows support.
> >
> >
> >
> > Sorry, but I can't see it. Which of your changed files contains windows
> > code? Also, please update your CL to the tip. I can't download it.
> > Probably, because Makefiles have been deleted now. Thank you.
> >
> > Alex
> >
> > http://codereview.appspot.com/5585043/
>
> Oh! I see the problem. I put the code on github while I tested various
> platforms and got some feedback, I have not yet updated the changeset.
>
> https://github.com/howeyc/fsnotify
>
> Sorry for the confusion I caused!
>
> Chris
>

[howeyc, 2012-04-04 03:38:38]

On 3 April 2012 19:54, Rob Figueiredo <robfig@gmail.com> wrote:

> Hi Chris,
> I'm having one problem with it:
> https://github.com/howeyc/fsnotify/blob/master/fsnotify_bsd.go#L187
>
> On that line, you ignore the returned errno.  For some reason, when I
> start up my server that configures and uses a watcher, the first Kevent
> call always fails with "interrupted system call".  That may be specific to
> my program (I'm not sure how to tell what it's doing to cause that -- any
> suggestions?), but it also causes a panic when on the next line when it
> indexes into the eventbuf slice.  Locally, I changed it to just continue if
> there was an error, and things seem to work fine.
>
> Thanks for doing this,
> Rob
>
>
Rob,

I've done some investigating, and it appears that ignoring the EINTR error
val is probably the way to go. EINTR appears to happen in two scenarios
(from what I can see looking over kernel sources, I may have missed
something):
1. While forking close to calling of kevent() - The process inside the
kevent() call with a timeout may get interrupted as the forking process
registers a new process with the same kqueue.
2. A file event occurs but is not yet available on the kqueue.

I have updated the code on github and should have the issue resolved, can
you confirm?

Thanks,
Chris

[robfig, 2012-04-04 13:29:35]

I'm afraid that doesn't quite fix it --
now it crashes on
https://github.com/howeyc/fsnotify/blob/master/fsnotify_bsd.go#L216

I think I was not clear earlier -- when I said continue I meant it
restarted the loop (ie the keyword), not that it continued executing :)

I think this would work:

if errno != nil {
  if errno != EINTR {
    w.Error <- os.NewSyscallError("kevent", errno)
  }
  continue
}



On Tue, Apr 3, 2012 at 11:38 PM, Chris Howey <howeyc@gmail.com> wrote:

>
> On 3 April 2012 19:54, Rob Figueiredo <robfig@gmail.com> wrote:
>
>> Hi Chris,
>> I'm having one problem with it:
>> https://github.com/howeyc/fsnotify/blob/master/fsnotify_bsd.go#L187
>>
>> On that line, you ignore the returned errno.  For some reason, when I
>> start up my server that configures and uses a watcher, the first Kevent
>> call always fails with "interrupted system call".  That may be specific to
>> my program (I'm not sure how to tell what it's doing to cause that -- any
>> suggestions?), but it also causes a panic when on the next line when it
>> indexes into the eventbuf slice.  Locally, I changed it to just continue if
>> there was an error, and things seem to work fine.
>>
>> Thanks for doing this,
>> Rob
>>
>>
> Rob,
>
> I've done some investigating, and it appears that ignoring the EINTR error
> val is probably the way to go. EINTR appears to happen in two scenarios
> (from what I can see looking over kernel sources, I may have missed
> something):
> 1. While forking close to calling of kevent() - The process inside the
> kevent() call with a timeout may get interrupted as the forking process
> registers a new process with the same kqueue.
> 2. A file event occurs but is not yet available on the kqueue.
>
> I have updated the code on github and should have the issue resolved, can
> you confirm?
>
> Thanks,
> Chris
>

[taralx, 2012-04-17 19:35:51]

I just took a glance over the code. This looks really exciting. :)

Shouldn't IN_DELETE_SELF be in the linux default set? BSD has NOTE_DELETE, which
is the same thing.

[howeyc, 2012-04-18 14:47:51]

On 2012/04/17 19:35:51, taralx wrote:
> I just took a glance over the code. This looks really exciting. :)
> 
> Shouldn't IN_DELETE_SELF be in the linux default set? BSD has NOTE_DELETE,
which
> is the same thing.

I've made the update to the code up on github. 

https://github.com/howeyc/fsnotify

It's up there for anyone who wants to use it. It works on Linux/BSD/OSX/Windows.

Is there any interest to bring this into the Standard library? If so, I'm
willing to update/create a change set to get this into exp/.

[dave_cheney.net, 2012-04-20 06:35:29]

I would like to see this integrated into the standard lib again. 

I think the best way to broach this is to raise the proposal on golang-dev. 

Dave

On 19/04/2012, at 0:47, howeyc@gmail.com wrote:

> On 2012/04/17 19:35:51, taralx wrote:
>> I just took a glance over the code. This looks really exciting. :)
> 
>> Shouldn't IN_DELETE_SELF be in the linux default set? BSD has
> NOTE_DELETE, which
>> is the same thing.
> 
> I've made the update to the code up on github.
> 
> https://github.com/howeyc/fsnotify
> 
> It's up there for anyone who wants to use it. It works on
> Linux/BSD/OSX/Windows.
> 
> Is there any interest to bring this into the Standard library? If so,
> I'm willing to update/create a change set to get this into exp/.
> 
> http://codereview.appspot.com/5585043/

[dave_cheney.net, 2012-09-19 09:26:34]

ping

[undriedsea, 2013-03-07 21:29:03]

On 2012/09/19 09:26:34, dfc wrote:
> ping

Any chance this will make 1.1?

[minux1, 2013-03-07 21:42:24]

On Fri, Mar 8, 2013 at 5:29 AM,  <tylor@torbit.com> wrote:
> Any chance this will make 1.1?
the corresponding issue (https://code.google.com/p/go/issues/detail?id=4068)
is labeled Go 1.1, so this is still possibility.

however, as this CL has sat idle for more than 10 months, it is fairly unlikely
to make into Go 1.1.

[rsc, 2013-03-11 15:41:31]

I apologize for letting this fall on the floor. I'm very interested in
seeing this functionality made available in a portable way - I've already
written code that can use it - but we don't have time to do the appropriate
API review to get this into Go 1.1. However, howeyc, if you'd like to send
us a CL adding it to the newly created go.exp repository, I'd be happy to
check it in there in its current form as a way for accumulate experience
with it. That will make it easier to roll into Go 1.2.

Thanks, and again my apologies.
Russ

[undriedsea, 2013-03-11 16:36:24]

Russ,

Side-note, if you need this for a current project, this is the github repo
that many people using fsnotify are using:
https://github.com/howeyc/fsnotify

Tylor Arndt
Software Engineer
Torbit <http://www.torbit.com>


On Mon, Mar 11, 2013 at 10:41 AM, Russ Cox <rsc@golang.org> wrote:

> I apologize for letting this fall on the floor. I'm very interested in
> seeing this functionality made available in a portable way - I've already
> written code that can use it - but we don't have time to do the appropriate
> API review to get this into Go 1.1. However, howeyc, if you'd like to send
> us a CL adding it to the newly created go.exp repository, I'd be happy to
> check it in there in its current form as a way for accumulate experience
> with it. That will make it easier to roll into Go 1.2.
>
> Thanks, and again my apologies.
> Russ
>
>

[howeyc, 2013-03-11 17:16:33]

On 2013/03/11 15:41:31, rsc wrote:
> I apologize for letting this fall on the floor. I'm very interested in
> seeing this functionality made available in a portable way - I've already
> written code that can use it - but we don't have time to do the appropriate
> API review to get this into Go 1.1. However, howeyc, if you'd like to send
> us a CL adding it to the newly created go.exp repository, I'd be happy to
> check it in there in its current form as a way for accumulate experience
> with it. That will make it easier to roll into Go 1.2.
> 
> Thanks, and again my apologies.
> Russ

I've gone head and taken the latest I had on github and created a change set for
the go.exp repository here: https://codereview.appspot.com/7497045/

[khr, 2013-07-22 20:56:18]

R=close