fs incorrectly handles mapped network drive on Windows

[borismedovnik]

This is very similar to #6861 where various fs functions erroneously consider files on a mapped network drive to be directories, however this time fs.watch demonstrates this behavior on the (currently) latest version of node:

• Version: v4.6.0
• Platform: 64-bit Windows 7 SP1 / cygwin: CYGWIN_NT-6.1 CompName 2.5.2(0.297/5/3) 2016-06-23 14:29 x86_64 Cygwin
• Subsystem: fs

Easiest way to reproduce is to run the following file: // test.js var fs = require ("fs"); fs.watch(__filename);

If executed in C:\Temp, fs.watch is executed normally (starts watching): C:\Temp> node test.js ^C C:\Temp>

If executed in a mapped network drive, for example X:\Temp: X:\Temp> node test.js fs.js:1236 throw error; ^

Error: watch X:\Temp\test.js EISDIR at exports._errnoException (util.js:907:11) at FSWatcher.start (fs.js:1234 :19) at Object.fs.watch (fs.js:1262:11) at Object. (X:\Temp\test.js:2:4) at Module._compile (module.js:409:26) at Object.Module._extensions..js (module.js:416:10) at Module.load (module.js:343:32) at Function.Module._load (module.js:300:12) at Function.Module.runMain (module.js:441:10) at startup (node.js:139:18)

X:\Temp>

Note that many people run into this issue because of using virtual machines, for example VirtualBox provides shared directories with the host as a mapped network drive, so it's impossible to run any node code (that uses fs functions) on a mapped host directory due to it being a network drive.

This happens on node 4.0.0 and on the latest 6.7.0.

[bnoordhuis]

That is probably unfixable. The documentation comments on it:

If the underlying functionality is not available for some reason, then fs.watch will not be able to function. For example, watching files or directories can be unreliable, and in some cases impossible, on network file systems (NFS, SMB, etc), or host file systems when using virtualization software such as Vagrant, Docker, etc.

You can still use fs.watchFile, which uses stat polling, but it is slower and less reliable.

[borismedovnik]

Is there any way to make this behaviour customizable (e.g. not throw irrelevant exception)? I have no control over the caller (the call happens in karma and due to this I can't run any karma tests on a virtual machine).

[bnoordhuis]

Node.js just forwards the error that the operating system reports. You probably need to take this up with karma.

[borismedovnik]

Thank you! I was just looking at karma sources and thanks to your comment about polling was able to find the relevant option in karma.

For anyone who gets here from google in the future, here's a simple way to resolve the issue, add: usePolling: process.platform == "win32" to your karma config to use polling mechanism. This resolves the issue on Windows networked drive, while keeping it unchanged for anyone who runs the same test on linux/mac.

[philippefutureboy]

Is there any update regarding the feasability of a fix for this one? If not, would there be any way to detect programmatically ahead of time if a device is a network disk? If so maybe the fs methods could call fs.watchFile by default instead? If not, would it be possible to at least make the fs_event_wrap throw a meaningful error within the JS runtime? It would really make debugging easier :)

Cheers ✨