Inconsistent behavior when watching for REMOVE event on single file

[denis-ismailaj]

I am using the latest fsnotify release v1.5.4.

Describe the bug
When a file that is being watched is removed, an event is triggered when running on macOS but not on Linux.

To Reproduce

Minimal reproducible example:

package main

import (
	"github.com/fsnotify/fsnotify"
	"log"
	"os"
	"time"
)

func main() {
	file, _ := os.CreateTemp("", "fsnotify-issue-reproduction")

	watcher, _ := fsnotify.NewWatcher()
	_ = watcher.Add(file.Name())

	ch := make(chan struct{})

	go func() {
		select {
		case event, _ := <-watcher.Events:
			log.Printf("%v", event)
		case <-time.After(1 * time.Second):
			log.Println("Event not received!")
		}
                ch <- struct{}{}
	}()

	_ = os.Remove(file.Name())
	<-ch
}

When on macOS, a REMOVE event's details are printed, while on Linux Event not received! is printed.

Expected behavior
The output should either be consistent across platforms or a warning should be added to inform users of the library of the differences.

Which operating system and version are you using?

Linux:
golang:1.18 Docker image

macOS:
ProductName: macOS
ProductVersion: 11.6.7
BuildVersion: 20G630

[dboslee]

See #260

[arp242]

Since #260 is merged you get a CHMOD event; with the example code:

2022/07/22 05:03:27 "/tmp/fsnotify-issue-reproduction1588982570": CHMOD

If you close the file (before or after removing it, doesn't matter) you get two events:

2022/07/22 05:04:59 "/tmp/fsnotify-issue-reproduction1570134148": CHMOD
2022/07/22 05:04:59 "/tmp/fsnotify-issue-reproduction1570134148": REMOVE

(note you do have to change the code to read multiple events: it reads just a single one now).

Arguably this isn't 100% ideal, but I'm not sure if it can be improved on without a lot of complexity; what it amounts to is that on inotify you only get a REMOVE if the file is removed and all file descriptors to it are closed. I don't really see a way to change that behaviour judging from inotify(7).

So I guess what should be done is that the documentation should be updated to clarify this.

[arp242]

I documented the behaviour described in my previous comment in the README; I think that's the best we can do.