Glob fails with ENOTSUP on Windows when working of network drive

[jvoccia]

Version 3.2.11:
Using Grunt which still uses this older version -- If this belongs over there, I can certainly move it. Not sure if you all are still maintaining the older versions.

When doing globs with paths that contain "**" like:
`"src/**/*.js"``
The error:
ENOTSUP, operation not supported on socket 'W:\folder\project\src\file.js'
Happens and the glob fails, when working off some Windows Network Mapped Drives using DFS (I am not sure of the specific underlying network filesystem details).

See also:
http://stackoverflow.com/questions/30199739/enotup-using-grunt

It looks like the error occurs specifically when the globber calls:
readdirsync on a file, and then gets the "unsupported" error back.

When it handles the error in glob.js ~Line 606:

 // now handle errors, and cache the information
if (er) switch (er.code) {
      case "ENOTDIR": // totally normal. means it *does* exist.
        this.statCache[f] = 1
        return cb.call(this, er)
      case "ENOENT": // not terribly unusual
      case "ELOOP":
      case "ENAMETOOLONG":
      case "UNKNOWN":
        this.statCache[f] = false
        return cb.call(this, er)
      default: // some unusual error.  Treat as failure.
        this.statCache[f] = false
        if (this.strict) this.emit("error", er)
        if (!this.silent) console.error("glob error", er)
          return cb.call(this, er)
    }
  }

It does not allows for the error "ENOTSUP" only the error "ENOTDIR", adding
case "ENOTSUP":
Right after `case "ENOTDIR":``
Seems to resolve the problem, but it is hard to know if this is the only situation this error would come up.

[isaacs]

Yeah, I wonder if there are any other cases where ENOTSUP might be raised by readdir other than "this is a regular file".

One approach might be to stat the file when we get an ENOTSUP just to make sure it is a real file that exists?

[isaacs]

Meh. Adding stat is a pita. Just gonna treat ENOTSUP the same as ENOTDIR. It already was shown on a previous readdir call, so it's probably there.

[jvoccia]

Hey thanks for the quick response. I can just keep back porting the change until grunt catches up (eventually).

[reyou]

I am having this issue while pushing on Azure. Is there any update on this?

** Grunt :: An error occurred. **

---

�[31mAborted due to warnings.�[39m
Running "clean:dev" (clean) task�[24m

�[33mWarning: ENOTSUP: operation not supported on socket, scandir 'D:\home\site\wwwroot.tmp\public\concat\production.css'� �[39m

Looks like a Grunt error occurred--
Please fix it, then restart Sails to continue running tasks (e.g. watching for changes in assets)
Or if you're stuck, check out the troubleshooting tips below.
�[4mTroubleshooting tips:�[24m

*-> Are "grunt" and related grunt task modules installed locally? Run npm install if you're not sure.

*-> You might have a malformed LESS, SASS, CoffeeScript file, etc.

*-> Or maybe you don't have permissions to access the .tmp directory?
e.g., D:\home\site\wwwroot\.tmp ?

 If you think this might be the case, try running:
 sudo chown -R YOUR_COMPUTER_USER_NAME D:\home\site\wwwroot\.tmp

Error: The hook grunt is taking too long to load.
Make sure it is triggering its initialize() callback, or else set sails.config.grunt._hookTimeout to a higher value (currently 90000) at tooLong [as _onTimeout] (D:\home\site\wwwroot\node_modules\sails\lib\app\private\loadHooks.js:85:21) at Timer.listOnTimeout (timers.js:92:15) { [Error: The hookgruntis taking too long to load. Make sure it is triggering itsinitialize()callback, or else setsails.config.grunt._hookTimeout to a higher value (currently 90000)] code: 'E_HOOK_TIMEOUT' }