babashka/pod-babashka-fswatcher

Duplicate events when :recursive true

fjsousa opened this issue · 3 comments

By quickly looking into it, it seems to be an expected behaviour because the watchers are being added to the base directory and to the file itself.

There's dedup logic as an example in fsnotify

Should this test assert that there's only one event? https://github.com/babashka/pod-babashka-fswatcher/blob/main/test/script.clj#L38

Steps to reproduce

I have a single file bb.edn in my dir

{:paths ["src"]
 :pods {org.babashka/fswatcher {:version "0.0.3"}}
 :tasks
 { watch {:requires ([pod.babashka.fswatcher :as fw]
                     [babashka.fs :as fs])
                :task (do (fw/watch "." prn {:recursive true :delay-ms 500})
                          (deref (promise)))}}}

I start my watcher:

[fsousa@work fs-watch-issue]$ bb watch 
{:type :write, :path "./bb.edn"}
{:type :write, :path "bb.edn"}
{:type :write, :path "./bb.edn"}
{:type :write, :path "bb.edn"}

then just modify bb.edn with a new line.

fsnotify has no api level functionality to deal with the duplicates, but the code in the example could be implemented easily.

I'm trying to understand what the debounce function is doing because it seems to intersect with dedupping, except for the cases where you get notifications on bb.edn and ./bb.edn because of the recursive flag.

After #19, this is the output I get after the steps above:

bb watch 
{:type :write, :path "./bb.edn"}

and by passing :dedup false to fw/watch we get the old behaviour back:

$ bb watch 
{:type :write, :path "./bb.edn"}
{:type :write, :path "bb.edn"}
{:type :write, :path "./bb.edn"}
{:type :write, :path "bb.edn"}

closed in #19