Expected Events API
Arcanemagus opened this issue · comments
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
- Have a terrible file system that sends some events but not most
- Watch
@atom/watcher
fail to see modification events - 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.