You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fs.watch(): EINVAL on Windows watching a root file #4643
> fs.watch("C:\\test.txt")
Error: watch C:\test.txt EINVAL
at exports._errnoException (util.js:874:11)
at FSWatcher.start (fs.js:1239:19)
at Object.fs.watch (fs.js:1267:11)
at repl:1:4
at REPLServer.defaultEval (repl.js:164:27)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
at REPLServer.<anonymous> (repl.js:393:12)
at emitOne (events.js:82:20)
at REPLServer.emit (events.js:169:7)
When watching files, I think libuv actually creates a watch on the parent directory of the file (https://github.com/libuv/libuv/blob/v1.x/src/win/fs-event.c#L188), in this case C:\\. Could that have something to do with it? Also, do you have appropriate permissions to access C:\\?
This looks like a bug in libuv. If the file is at the root, and we try split the path into a directory name and file name (https://github.com/libuv/libuv/blob/f1a13e9b4abe8c97768a1d38b12ca3766c8a9b34/src/win/fs-event.c#L198-L206), we end up with a directory name that doesn't have a trailing backslash, e.g. \\?\C:. When passing that to CreateFile() Windows thinks we are trying to open the drive rather than the root directory. Adding a trailing backslash fixes the issue.
I'll add this to my queue of fixes. If anyone else wants to open a PR to https://github.com/libuv/libuv, you are welcome to do so. Thanks for reporting this issue!
Activity
mscdex commentedon Jan 12, 2016
/cc @nodejs/platform-windows
jorangreef commentedon Jan 12, 2016
When watching files, I think libuv actually creates a watch on the parent directory of the file (https://github.com/libuv/libuv/blob/v1.x/src/win/fs-event.c#L188), in this case
C:\\. Could that have something to do with it? Also, do you have appropriate permissions to accessC:\\?bpasero commentedon Jan 12, 2016
Yes, otherwise you will get an EPERM
orangemocha commentedon Jan 12, 2016
This looks like a bug in libuv. If the file is at the root, and we try split the path into a directory name and file name (https://github.com/libuv/libuv/blob/f1a13e9b4abe8c97768a1d38b12ca3766c8a9b34/src/win/fs-event.c#L198-L206), we end up with a directory name that doesn't have a trailing backslash, e.g.
\\?\C:. When passing that to CreateFile() Windows thinks we are trying to open the drive rather than the root directory. Adding a trailing backslash fixes the issue.I'll add this to my queue of fixes. If anyone else wants to open a PR to https://github.com/libuv/libuv, you are welcome to do so. Thanks for reporting this issue!
CxRes commentedon Mar 22, 2016
@saghul @seishun Has this change been upstreamed? I still have this problem with node 5.9.0.
saghul commentedon Mar 23, 2016
@CxRes It's part of libuv but not yet of any release. It will be part of the next one, which should happen by Node 6.0.
CxRes commentedon Mar 23, 2016
@saghul Thanks!
deps: upgrade libuv to 1.9.0
deps: upgrade libuv to 1.9.0
deps: upgrade libuv to 1.9.0
deps: upgrade libuv to 1.9.0
deps: upgrade libuv to 1.9.0
deps: upgrade libuv to 1.9.0
deps: upgrade libuv to 1.9.0