Watcher emits create event for quickly deleting and recreating a file about watcher HOT 6 CLOSED

Same reply as #71.

from watcher.

Does that apply even to Windows? My tests resulted in the same on both platforms.

This might be a bit harder for VS Code to digest in case of atomic writes. But I need to test with our previous watchers if they behaved any different...

from watcher.

Hmm I think the logic is here:

Perhaps we should have a case for both created and deleted that emits "updated" instead? It would still not happen all the time on macOS but should be a bit better elsewhere. I think we'd have to skip such a test on macOS. I guess that's why I did it this way - so it's consistent across platforms.

from watcher.

I am not sure this kind of event normalization should happen in the watcher: in the end what happens on disk is a delete followed by a create, so if anyone wants to normalize that to an "updated" event, they should do it. For the watcher I think it is important to distinguish though.

But if the watcher itself does not emit these 2 events, a client cannot do this.

I wonder if your structure of known files could help here (State)?

from watcher.

This issue is now being reported as microsoft/vscode#136460 for VS Code where it looks like the git process deletes and writes the .git/HEAD file very quickly. Previously extensions would listen to change events on this file to react and now have to change to listen to create events.

I was able to verify that our previous watchers reported the create+delete events and we did fold the event into a single change event.

from watcher.

... but linux uses inotify and one must remonitor that file after create! Coalescing that into modify breaks watching on linux.

This breaks on linux when used for example with git or (unmodified) vim.

from watcher.