Error for non-registered events?

[markschmid]

Following up on your last comment in #16, here's what I mean:

1. I'm running your example handlers.go 1:1
2. I'm creating a subdirectory in the watched directory
3. I see 2019/11/19 20:23:38 Directory created: mysubdir in the console
4. I'm removing the subdirectory
5. I see 2019/11/19 20:23:40 handle not found: event mask: 32768in the console (triggered by line 75 of handlers.go, printing an error)

Step 5 is what confuses me. Does this mean that all unregistered fs events throw an error (instead of e.g. be disregarded)? Thanks!

[tywkeene]

Does this mean that all unregistered fs events throw an error (instead of e.g. be disregarded)?

go-fsevents/fsevents.go

Line 588 in ba477e9

w.Errors <- fmt.Errorf("%s: event mask: %d", ErrNoSuchHandle, event.RawEvent.Mask)

Yep, looks like it. I've debated on if this is good design or not, but I feel like checking the error type against the ErrNoSuchHandle error from fsevents is the most pragmatic and correct way to go about it.

[markschmid]

Thanks for the explanation. Makes sense.

[markschmid]

I've tried checking for ErrNoSuchHandle but it's not working, possibly because in line 588 not an error, but a string is sent to w.Errors

Also, when removing a directory, my &DirectoryRemovedHandle handle is called correctly and it removes the watch event for that directory from the watcher. But I'm still getting a "no such handle" error string with event mask 32768 (which supposedly means IN_IGNORED). Where could that come from?

[tywkeene]

I've tried checking for ErrNoSuchHandle but it's not working, possibly because in line 588 not an error, but a string is sent to w.Errors

You're right. The formatting with fmt.Errorf is the issue. It's still an error type, but the comparison fails because of the extra text in the string.

I actually recall running into this when I was writing this function. I didn't want to lose the event mask that goes along with the error, and did it this way, but it seems that was short sighted.

I hate to do this for such a one-part-of-the-code case, but I think wrapping the actual fsevent and error in one structure and passing that over the channel might be the best solution, since it relays the error and includes the context so you know what mask is being problematic. I'll take a look and see what else I can come up with and update here.

Thanks for your input, really appreciate it.

[markschmid]

That's great, thanks!

In regards to the second issue, I'm watching a single directory and am interested in 3 events: file created, directory created, directory removed.

All events are working fine, but for "directory removed" events, I'm getting the 32768 mask "no such handle" error.

This is the code in main:

...
var mask uint32 = fsevents.DirCreatedEvent | fsevents.DirRemovedEvent | fsevents.FileCreatedEvent

w, err := fsevents.NewWatcher()

err = w.RecursiveAdd(watchDir, mask)
if err != nil {
  log.Error("recursive add failed: ", err)
}

// Register event handles
w.RegisterEventHandler(&DirectoryCreatedHandle{Mask: fsevents.DirCreatedEvent})
w.RegisterEventHandler(&DirectoryRemovedHandle{Mask: fsevents.DirRemovedEvent})
w.RegisterEventHandler(&FileCreatedHandle{Mask: fsevents.FileCreatedEvent})
...