rjeczalik / notify

File system event notification library on steroids.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

FSEvents are sometimes not notified due to strip() logic following rename

ReallyLiri opened this issue · comments

commented

For example in the following action flow on Mac OSX 12.0.1

touch test.txt
mv test.txt renamed.txt
touch test.txt

We do not get notified of the second create of the file.
Logs:

# touch test.txt
2023/03/16 10:50:40.590694 [D] notify.Create|notify.FSEventsIsFile (0x10100) (/Users/liri/tmp/dv_tests/liri-2/test.txt, i=0, ID=91389624, len=1)
2023/03/16 10:50:40.590739 [D] split()=notify.Create|notify.FSEventsIsFile
2023/03/16 10:50:40.590747 [D] 91389624: single event: notify.Create
2023/03/16 10:50:40.591065 [D] dispatching notify.Create on "/Users/liri/tmp/dv_tests/liri-2/test.txt"

# mv test.txt renamed.txt
2023/03/16 10:52:05.820897 [D] notify.Rename|notify.FSEventsIsFile (0x10800) (/Users/liri/tmp/dv_tests/liri-2/test.txt, i=0, ID=91390335, len=2)
2023/03/16 10:52:05.820985 [D] split()=notify.Rename|notify.FSEventsIsFile
2023/03/16 10:52:05.820997 [D] 91390335: single event: notify.Rename
2023/03/16 10:52:05.821023 [D] notify.Rename|notify.FSEventsIsFile (0x10800) (/Users/liri/tmp/dv_tests/liri-2/renamed.txt, i=1, ID=91390336, len=2)
2023/03/16 10:52:05.821032 [D] split()=notify.Rename|notify.FSEventsIsFile
2023/03/16 10:52:05.821039 [D] 91390336: single event: notify.Rename
2023/03/16 10:52:05.821609 [D] dispatching notify.Rename on "/Users/liri/tmp/dv_tests/liri-2/test.txt"
2023/03/16 10:52:05.821634 [D] dispatching notify.Rename on "/Users/liri/tmp/dv_tests/liri-2/renamed.txt"

# touch test.txt
2023/03/16 10:52:24.918202 [D] notify.Create|notify.FSEventsIsFile (0x10100) (/Users/liri/tmp/dv_tests/liri-2/test.txt, i=0, ID=91390549, len=1)
2023/03/16 10:52:24.918230 [D] split()=notify.FSEventsIsFile

You can see its due to the Create flag being stripped from the event.

I suspect the logic of strip() (watcher_fsevents.go) should handle rename events (as create/delete), however since in rename we don't easily know which "side" of the event we handle, I don't see an immediate fix.