Expected Events API

[Landon Abney]

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

There are some terrible file systems out there that send some events (file creation/deletion), but fail to send other events (file modifications). Since @atom/watcher sees the initial events it doesn't consider that it needs to fall back to polling for this file system, which ends it up in a state where it can only detect when a file has been created or deleted.

Expected Events

One way that this could be solved is an "expected events" API, where the client (Atom) sends a message when it thinks there should be an event happening, then @atom/watcher will immediately emit the event back... but watch for the real event from the file system. If it gets the real event within a threshold it marks the file system as correctly sending that specific event type and ignores the real event. If the real event is never seen before the threshold expires the filesystem is marked as "problematic" for that event and @atom/watcher will know that it needs to poll for changes on that root.

Advantages

• Known events are emitted back immediately
• No additional I/O for filesystem capability checks

Disadvantages

• Added complexity of interacting with @atom/watcher
• Will fail to detect externally triggered events till the client does I/O on a file under the root being watched

Token files

An alternative solution that has been talked about before is having @atom/watcher create its own "token" file within the filesystem root to check if the events are properly being emitted for the file.

Advantages

• Will know as soon as the token file I/O is complete whether the filesystem works correctly or not

Disadvantages

• Additional I/O work for the token file
• Has to write a file for every root
• Doesn't work for read only file systems

Steps to Reproduce

1. Have a terrible file system that sends some events but not most
2. Watch @atom/watcher fail to see modification events
3. Think of a way to get around this

Expected behavior:

@atom/watcher works everywhere, all the time.

Actual behavior:

It doesn't.

Reproduces how often:

100% of the time.

Versions

All of them up till this gets fixed.