External file changes are not detected

[HungryJake]

when we are running a file watcher in bashOnWindows. Any external files updates from windows programs can't be caught by the watch. I'm running MeteorJS on bashOnWindows. When I'm editing a file externally using an editor such as Visual Studio Code. The meteor watcher doesn't pick up any file save changes and restart the meteor server.

[benhillis]

Can you clarify a few things for me?

1. That directory are you working out of (/mnt/c or somewhere like your home directory).
2. Do file modifications from within bash show up with MeteorJS?
3. Do you happen to know how MeteorJS is registering for file change notifications? Inotify?

[fpqc]

@benhillis I just did a test with the watch util

watch -n 0.2 "ls -lh test.txt"

where test.txt was a file I was editing and saving in Notepad.

As soon as I saved the file, my watcher did update the size correctly as long as the file test.txt was in driveFS.

On the other hand, when I tried to do
tail -f test.txt

it spits out an error message:

tail: unrecognized file system type 0x53464846 for ‘test.txt’. please report this to bug-coreutils@gnu.org. reverting to polling

However, tail -f does work in polling mode after that.

It might be that Meteor's watcher uses the same kind of watcher as tail -f (and is failing bc of a filesystem thing), or maybe he's working inside of %localappdata%\LXSS (which would cause obvious problems)

[therealkenc]

Meteor is exceptionally clever about avoiding #216, and does its best with a stat() storm.

The tail -f issue @fpqc found is interesting though. tail is checking a whitelist of fs magic numbers and can't grok fs type 0x53464846. As a result it punts defensively to stat polling, and avoids inotify altogether. Possibly WSL should lie like a rug and return S_MAGIC_NTFS for NTFS on DrvFs. Looks like the bug-coreutils people have already picked up on it.

[benhillis]

@therealkenc Good call. This isn't the first time our fstype has caused bad behavior. I think you're right though if we report S_MAGIC_NTFS things might work a lot better.

[therealkenc]

I think it is a seriously hard question what to return, with no right answer. One can also imagine a Samba daemon on WSL looking at the fstype magic number and saying "NTFS share, no unix symlinks for you!", even though DrvFs has the new reparse points.

[therealkenc]

The OP on this one is #216. The tail thing is #925.