Only detecting changes in a file once

[Shashankft9]

Before reporting an issue, please ensure you are using the latest release of fsnotify.

Which operating system (GOOS) and version are you using?

Centos 8

Please describe the issue that occurred.

I am mounting a configmap to my pod, and I can see the file coming up inside the container. Everything works fine for the first change in the file but after that nothing happens. Note that I am editing my configmap (k8s resource) and the changes are reflected back in the container file as well, only that watcher only works for the first event.
I found this relevant issues but with no concrete resolutions? #94

I am using the sample code provided on this repo.

[YoghurtFree]

Before reporting an issue, please ensure you are using the latest release of fsnotify.

Which operating system (GOOS) and version are you using?

Centos 8

Please describe the issue that occurred.

I am mounting a configmap to my pod, and I can see the file coming up inside the container. Everything works fine for the first change in the file but after that nothing happens. Note that I am editing my configmap (k8s resource) and the changes are reflected back in the container file as well, only that watcher only works for the first event.
I found this relevant issues but with no concrete resolutions? #94

I am using the sample code provided on this repo.

I had the same problem，wait for reply...

[zhipengzuo]

same problem

[nathany]

Thanks for reporting the issue. I'm not sure if there is a straight-forward fix, because we may be dealing with limitations of the underlying inotify system.

However, a good place to start would be to come up with a failing test case or step-by-step instructions to reproduce it. The simpler (fewer steps) the better.

[mdean75]

I just encountered this same issue, but I believe it may be related to how the file is edited, at least in my case anyway. The environment is OEL7 Linux VM (see below for more env details). What I found:

• only editing a file by echoing a string and redirecting that to append to the target file, events would continue to get triggered
• after editing the file using vim, I would see multiple events come in (RENAME, MOD, REMOVE - in that order) after that no more events would get triggered for that particular file no matter which method I used to edit the file.

When looking into it, I found some information about how vim or vi edits files, which is of course configurable with a vimrc file, but the default behavior is to create a temp file and replace the original file with the edited temp file on save. So then based on this, I believe the file being watched is no longer present.

My solution was to re-add the file at the end of the event handling if the event is not WRITE. This appears to have fixed my issue without any unintended problems. I'm thinking that I should probably also remove the file from the watcher before re-adding so as not to go over the system limit of watched files.

ENV:
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: OracleServer
Description: Oracle Linux Server release 7.8
Release: 7.8
Codename: n/a
vim: defaults

func main() {

w, err := fsnotify.NewWatcher()
if err != nil {
	fmt.Println(err)
	os.Exit(1)
}

defer w.Close()

done := make(chan bool)
go func() {
	for {
		select {
		case event, ok := <-w.Events:
			if !ok {
				return
			}
			fmt.Println("event:", event)
			
			if event.Op&fsnotify.Write == fsnotify.Write {
				fmt.Println("modified file:", event.Name)
				continue
			}
			w.Add(event.Name)   // re-add the file here
		case err, ok := <-w.Errors:
			if !ok {
				return
			}
			fmt.Println("error:", err)
		}
	}
}()

w.Add("/test1.txt")
w.Add("/test2.txt")

<-done
}

[zhipengzuo]

maybe you can try "github.com/docker/docker/pkg/filenotify" to replace fsnotify which returns a poll-based file watcher

[fengqi]

same problem, and i found don't use return, and all be fine

if event.Op&fsnotify.Create != fsnotify.Create {
    return # use continue
}

[arp242]

Difficulties with watching a single file that gets edited with editors is tracked in #372; the general strategy is to watch the directory rather than the file. so on a remove + rename things will keep working. That seems to be the issue mdean75 was experiencing.

Other than that, this doesn't really contain enough information to be actionable; the original problem description is somewhat vague as in that it doesn't really contain clear steps to reproduce the issue, but I think it's probably the same problem(?) so I'm closing it for the time being.