1

I'm trying to use Java File Watcher to listen for changes in a file. When I edit the file with vim the File Watcher detect the changes. But when I replace word in file using sed, the file watcher doesn't recognize the changes. I can see the modify date is right.

watchService = FileSystems.getDefault().newWatchService();
Path parent = file.getParent();
parent.register(watchService,
                StandartWatchEventKinds.ENTRY_MODIFY
);

The sed command looks something like that:

sed -i 's/a/b/g' file.csv

The sed command itself works, the file actually get changed and the modified date is changed also but for some reason the fire watcher doesn't

Java version - openjdk version 1.8.0_222

Update

So I've got it working, At the beginning I tried an ansible script and I have used the module 'replace' and it didn't word, therefor I tried to change the file locally with sed as mentioned above with no success.

Now I've got it working by making a different ansible script, In the new script I have copied the wanted file to a tmp file using cp command, then using the 'replace' module on the tmp file and finally copying the tmp file back to the wanted one.
I'm not really sure why that solved it.

I've also found out that using the 'copy' module of ansible for the process I've described above doesn't help, an just buy using shell cp it fires the filewatcher.

Even if I've solved it I would like to hear if you know why does the file watcher doesn't fire when changes are made using sed

Mooo
  • 51
  • 3

1 Answers1

0

Many languages implement some "file watcher" monitoring capability. It usually boils down to using some kernel capability (e.g. inotify on Linux). While that works quite well on local filesystems (although with some limitations on the number of files being watched), it often fails on remote mounted ones. This SO answer is an excellent explanation of this.

In our team, we routinely monitor millions of files for change/deletion/creation, including on remote locations, but this relies on polling (in an optimized, parsimonious way) and caching. Before implementing this, we tried and looked at other options (including inotify and watchdog) in various languages, but realized they all failed to detect reliably changes on remote NFS.

Some hints if you'd like to embark on something like this:

  1. stat a single dir is very fast, but it only detects certain changes (new file/subdir, deleted file/subdir) and not some modification of files/subdirs;
  2. glob a pattern for ~10K files can be ~50x faster than stat those files on a remote NFS;
  3. often (but not always) the files that were last changed are the most likely to change again: maintain a 'tail' of those for fast checks, but periodically do a full scan.
Pierre D
  • 13,780
  • 6
  • 42
  • 72