On my laptop, fswatch was working, but is no more. Forcing -m poll_mo…

[ismith]

…nitor fixes it.

Specifically, I was getting events for IsDir and PlatformSpecific, and
nothing else, which is not helpful. Not sure why.

In theory, inotify (default on linux) has worse performance than
poll_monitor; in practice, for a 28k file repo, this should be fine.
http://emcrisostomo.github.io/fswatch/doc/1.5.1/html/fswatch/Monitors.html#The-Poll-Monitor:
"The authors’ experience indicates that fswatch requires approximately
150 MB of RAM memory to observe a hierarchy of 500,000 files with a
minimum path length of 32 characters. A common bottleneck of the poll
monitor is disk access, since stat()-ing a great number of files may
take a huge amount of time."

[ismith]

Need to confirm if this is just my personal laptop or also my dark laptop. (Both
ubuntu 18.04.)

[ismith]

This report matches my observations and my version (<1.12): emcrisostomo/fswatch#191 (comment)

And below:

On Arch it seems to do nothing at first glance, but only if the number of files in the directory is huge. For example, some project root with a big node_modules in it. If I repeat the experiment on a folder with a few files, fswatch seems to work fine on both MacOs and Linux.

After I've noticed this, I've repeated the experiment on the initial big directory. I decided to wait longer until fswatch recognizes something. And it does! But after a long, long time :)

Updating to 1.13 didn't seem to help, though 🤷‍♂️

[IanConnolly]

lgtm!

i will have this problem later this week when i switch to linux, so you will have a buddy in suffering :)

[pbiggar]

One option here is to add directories to ignore. Also, if you have any node_modules or _build directory outside the container, you can delete them now since I merged #308.