Node: Error: EISDIR illegal operation on directory - Binding.realpath

[sethdorris]

Version: 6.1.0
Platform: Windows 7 64-bit
Subsystem: Unknown

I have a project located here:
www.github.com/sethdorris/chatapp

Prior to upgrade Node to v6.0.0 this application was fully functional.
After upgradted Node to v6.0.0 and then again to v6.1.0, this project no longer builds (and there have been no code changes since the upgrade).. In addition, I have had other users pull the project and have been successful at building the application and running it. The following error is what I receive when I try to run the file:

server.js

from the build/server directory after executing the default Gulp task.

PS U:\Desktop\chatapp\build\server> node server.js
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^

Error: EISDIR: illegal operation on a directory, realpath 'U:\Desktop\chatapp\build\server\server.js'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at Function.Module._findPath (module.js:165:25)
    at Function.Module._resolveFilename (module.js:436:25)
    at Function.Module._load (module.js:386:25)
    at Function.Module.runMain (module.js:575:10)
    at startup (node.js:160:18)
    at node.js:445:3

[jasnell]

In Node.js v6, the fs.realpath implementation was changed to use a faster, libuv based implementation as opposed to the JavaScript based implementation in prior versions. While the old implementation did not throw certain kinds of errors, the new implementation _does_. This is likely a case where the new implementation is seeing an error condition where the old implementation simply would have passed over it.

I'm not _quite_ sure why you would be getting this specific error (that would be for @bnoordhuis and @saghul to explain ;-) ..) but the change in implementation explains why this error is suddenly appearing in v6 when it did not appear before.

[jasnell]

One quick thing to try, however: v6.2.0 just came out a day or so ago. Can you give it a test to see if you're seeing the same issue?

[sethdorris]

Also, this does not occur with every machine / user that tries to build this application using Node v6+ ... the user that successfully ran the application in attempt to assist with debugging, was using Node v6.1

[addaleax]

@sethdorris This looks like something is up with your directory structure. Can you run other .js files in the same directory? Is this #6500?

[mscdex]

@sethdorris Out of curiosity, is U:\ a special drive, like a mounted network share or something other than a local disk?

[sethdorris]

@mscdex, yes I am on a work machine, so it is a mounted drive

[saghul]

One quick thing to try, however: v6.2.0 just came out a day or so ago. Can you give it a test to see if you're seeing the same issue?

There have been no changes to uv_fs_realpath in this last release.

@sethdorris

Error: EISDIR: illegal operation on a directory, realpath 'U:\Desktop\chatapp\build\server\server.js'

That's weird, it complains about that path being a directory?! What happens if you run fs.statSync on it?

[jasnell]

@saghul ... no, but we did revert the symlink changes in module and put the new behavior behind a flag. Basically I want to rule out that those changes had anything to do with this (doesn't sound like it tho)

[sethdorris]

@saghul, sorry I am not an expert with node, how do I run fs.statSync on my server.js?

[mscdex]

@sethdorris

node -pe "require('fs').statSync('U:\\Desktop\\chatapp\\build\\server\\server.js')"

[sethdorris]

@mscdex

PS U:\Desktop\chatapp\build\server> node -pe "require('fs').statSync('U:\\Desktop\\chatapp\\build\\server\\server.js')"

{ dev: 0,
  mode: 33206,
  nlink: 0,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 0,
  size: 3049,
  blocks: undefined,
  atime: 2016-05-18T16:22:03.591Z,
  mtime: 2016-05-18T16:22:03.594Z,
  ctime: 2016-05-18T16:22:03.600Z,
  birthtime: 2016-05-18T16:22:03.591Z }
PS U:\Desktop\chatapp\build\server>

[addaleax]

Not a Windows person but that looks fine to me, mode says it’s a regular file.

@sethdorris Does node -p 'fs.statSync("server.js")'return the same outout? Does doing node -p 'fs.realpathSync("server.js")' manually work for you?

[sethdorris]

@addaleax the first command outputs the same as the node -pe I ran earlier...

realpathSync fails with same error as my first post.

[addaleax]

@sethdorris Which one of

node -p 'fs.realpathSync("U:\\")'
node -p 'fs.realpathSync("U:\\Desktop\\")'
node -p 'fs.realpathSync("U:\\Desktop\\chatapp\\")'
node -p 'fs.realpathSync("U:\\Desktop\\chatapp\\build\\")'
node -p 'fs.realpathSync("U:\\Desktop\\chatapp\\build\\server\\")'
node -p 'fs.realpathSync("U:\\Desktop\\chatapp\\build\\server\\server.js")'

is the first to fail?

[sethdorris]

@addaleax

I can't get any output ...

PS U:\Desktop\chatapp\build\server> node -p 'fs.realpathSync("U:\\")'
[eval]:1
fs.realpathSync(U:\)
                ^
SyntaxError: missing ) after argument list
    at Object.exports.runInThisContext (vm.js:53:16)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:541:32)
    at node.js:329:29
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

So I switched the double quotes and single quotes and re ran
 PS U:\Desktop\chatapp\build\server> node -p "fs.realpathSync('U:\\
>> node -p "fs.realpathSync('U:\\')"
>>

it just stays on >> and does nothing..

[sethdorris]

.. I just pulled the repo from my mac and ran the server with Node and the application successfully launched.. no issues.

[addaleax]

Eh, sorry, you may have to switch ' and ". The double escape \ -> \\ is important, though.

[sethdorris]

PS U:\Desktop\chatapp\build\server> node -p "fs.realpathSync('U:\\')"
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^
Error: EISDIR: illegal operation on a directory, realpath 'U:\'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at [eval]:1:4
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:541:32)
    at node.js:329:29
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)
 PS U:\Desktop\chatapp\build\server>

[addaleax]

@sethdorris Are you sure there’s nothing special about your U: drive? Does this work with other drives, e.g. C:?

[sethdorris]

@addaleax after copying and pasting over to C:\ .. it worked like a charm..

but why did 4.4 allow me run node on U:\ a virtual drive, and 6.1.0 no longer does?

[addaleax]

I think @jasnell explained _why_ this changed in https://github.com/nodejs/node/issues/6861#issuecomment-220094552 quite well… basically, the underlying implementation of fs.realpath changed to a much more efficient one.

/cc @nodejs/platform-windows

[sethdorris]

Is that something that will need to be fixed, or is it just known not to try to work on projects on virtual drives?

[addaleax]

I think it’s something that needs to be fixed, but probably rather in libuv than in Node.js… @saghul?

[addaleax]

@sethdorris I can’t reproduce this with a simple virtual drive. Can you provide information on how this drive has been created?

[saghul]

Can you provice the simplest possible way to reproduce this?

[sethdorris]

@addaleax I contacted my work admin for an explanation on how the drive was created.

Update: “U” drive is a network home folder derived by Active Directory.

[josh-endries]

I am experiencing what seems to be the same issue on my PC with a RAM drive mounted at R:, which might be easier to repro than setting up AD... I'm pretty sure something broke or regressed, because this was working about 10 minutes ago with Node 4.x. I upgraded in order to get mkdtempSync(), and now it doesn't work. It doesn't even get to my script; changing the script content doesn't make any difference. Permissions in the Windows GUI look fine and it seems normal from other apps (like Explorer), and I can run programs from it (i.e. there isn't some weird noexec mount flag, not that Windows has those anyway). I am using imdisk 1.7.6 to create the RAM disk on startup via imdisk -a -o awe -s 4096M -S 4096 -m R: -p "/fs:ntfs /v:RAM /A:4096 /q /y". I see that there is a newer version of that, so I'll try updating that and report back, in case that helps, though that will take a bit because I'll have to restart. In the meantime here is some monospace:

C:\>node -v
v6.2.2

C:\>type R:\Temp\MMfFOS\ts-output.js
console.log(process.argv);

C:\>node R:\Temp\MMfFOS\ts-output.js
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^

Error: EISDIR: illegal operation on a directory, realpath 'R:\Temp\MMfFOS\ts-output.js'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at Function.Module._findPath (module.js:167:25)
    at Function.Module._resolveFilename (module.js:438:25)
    at Function.Module._load (module.js:388:25)
    at Module.runMain (module.js:575:10)
    at run (node.js:348:7)
    at startup (node.js:140:9)
    at node.js:463:3

C:\>node -p 'fs.realpathSync("R:\\")'
fs.realpathSync(R:)

C:\>node -p 'fs.realpathSync("R:\\Temp")'
fs.realpathSync(R:\Temp)

C:\>node -p 'fs.realpathSync("R:\\Temp\\MMfFOS")'
fs.realpathSync(R:\Temp\MMfFOS)

C:\>node -p 'fs.realpathSync("R:\\Temp\\MMfFOS\\ts-output.js")'
fs.realpathSync(R:\Temp\MMfFOS\ts-output.js)

C:\>node -pe "require('fs').statSync('R:')"
{ dev: -1372767024,
  mode: 16822,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 281474976744378,
  size: 0,
  blocks: undefined,
  atime: 2016-06-18T20:39:39.914Z,
  mtime: 2016-06-18T20:39:39.914Z,
  ctime: 2016-06-18T20:39:39.914Z,
  birthtime: 2016-06-18T20:37:41.419Z }

C:\>node -pe "require('fs').statSync('R:\\Temp')"
{ dev: -1372767024,
  mode: 16822,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 281474976710691,
  size: 0,
  blocks: undefined,
  atime: 2016-06-18T21:01:35.712Z,
  mtime: 2016-06-18T21:01:35.712Z,
  ctime: 2016-06-18T21:01:35.712Z,
  birthtime: 2016-06-10T21:00:53.946Z }

C:\>node -pe "require('fs').statSync('R:\\Temp\\MMfFOS')"
{ dev: -1372767024,
  mode: 16822,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 281474976744378,
  size: 0,
  blocks: undefined,
  atime: 2016-06-18T20:39:39.914Z,
  mtime: 2016-06-18T20:39:39.914Z,
  ctime: 2016-06-18T20:39:39.914Z,
  birthtime: 2016-06-18T20:37:41.419Z }

C:\>node -pe "require('fs').statSync('R:\\Temp\\MMfFOS\\ts-output.js')"
{ dev: -1372767024,
  mode: 33206,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 281474976744379,
  size: 28,
  blocks: undefined,
  atime: 2016-06-18T20:37:42.403Z,
  mtime: 2016-06-18T20:42:28.268Z,
  ctime: 2016-06-18T20:42:28.268Z,
  birthtime: 2016-06-18T20:37:42.403Z }

Doing any of this stuff from R: directly rather than C: doesn't make a difference.

[addaleax]

@fzzzt With windows, you’ll need to use node -p "fs.realpathSync('R:\\')" instead of node -p "fs.realpathSync('R:\\')" (double quotes on the outside).

[josh-endries]

Oops, thanks, different output with that but no overall change with the latest imdisk:

C:\Users\Josh>node -p "fs.realpathSync('R:\\')"
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^
Error: EISDIR: illegal operation on a directory, realpath 'R:\'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at [eval]:1:4
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:541:32)
    at node.js:311:29
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

C:\Users\Josh>node -p "fs.realpathSync('R:\\Temp')"
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^
Error: EISDIR: illegal operation on a directory, realpath 'R:\Temp'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at [eval]:1:4
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:541:32)
    at node.js:311:29
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

C:\Users\Josh>node -p "fs.realpathSync('R:\\Temp\\test.js')"
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^
Error: EISDIR: illegal operation on a directory, realpath 'R:\Temp\test.js'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at [eval]:1:4
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:541:32)
    at node.js:311:29
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

C:\Users\Josh>node R:\Temp\test.js
fs.js:1568
  return binding.realpath(pathModule._makeLong(path), options.encoding);
                 ^

Error: EISDIR: illegal operation on a directory, realpath 'R:\Temp\test.js'
    at Error (native)
    at Object.realpathSync (fs.js:1568:18)
    at Function.Module._findPath (module.js:167:25)
    at Function.Module._resolveFilename (module.js:438:25)
    at Function.Module._load (module.js:388:25)
    at Module.runMain (module.js:575:10)
    at run (node.js:348:7)
    at startup (node.js:140:9)
    at node.js:463:3

C:\Users\Josh>node -pe "require('fs').statSync('R:')"
{ dev: 1449300398,
  mode: 16822,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 1407374883553285,
  size: 0,
  blocks: undefined,
  atime: 2016-06-18T21:50:23.512Z,
  mtime: 2016-06-18T21:50:23.512Z,
  ctime: 2016-06-18T21:50:23.512Z,
  birthtime: 2016-06-18T21:50:10.059Z }

Of course a RAM disk might be significantly different from an AD share at this level... I have network shares too, but not AD, just CIFS...hmmm...

C:\Users\Josh>echo console.log('hi'); > z:\test.js

C:\Users\Josh>node z:\test.js
hi

C:\Users\Josh>

Well nuts.

[josh-endries]

I played around with a lot of settings in imdisk to see if that matters...disk size, sector size, backing store (vmem, file), removable/fixed disk, but nothing changed the outcome, same error.

[bnoordhuis]

I speculate that the GetFinalPathNameByHandle(VOLUME_NAME_DOS) call fails with ERROR_INVALID_FUNCTION. Libuv maps it to EISDIR for historic (and arguably wrong) reasons.

I can't say for sure but it's quite possibly a bug in the ramdisk driver. For example, if it doesn't support CreateFile(FILE_FLAG_BACKUP_SEMANTICS), then the GetFinalPathNameByHandle call is going to fail for directories and empty files.

[josh-endries]

Thanks for the response, you are likely correct, at least in general if not specifically. I tried a different RAM disk program that emulates a SCSI volume, not just a disk, and that worked, so it seems to be some sort of incompatibility between ImDisk and the new lib in Node. I attempted to contact the author of ImDisk and pointed to/referenced this issue to see if he can confirm the behavior. I looked at the code for ImDisk but it's, uh, over my head. :)

[derekstavis]

Hi. I'm having the same issue and I can reproduce the error successfully using a VirtualBox 32 bit VM with Windows 7 SP1 and Node 6.2.2. The issue doesn't happen for me in C: or D: drive, but only on drives manually network-mapped or mounted automatically by VirtualBox's shared folders (which is basically the same thing).

In my testing, C:and D: are local drives, and E:, F: and H: are network mapped drives:

[saghul]

@derekstavis Thanks, that should make it easy to reproduce.

[saghul]

@fzzzt I could reproduce it with imdisk. Let's see if I can come up with a fix.

[josh-endries]

After talking with the imdisk author he tipped me off to the aim_ll CLI utility, which is based on imdisk but does include the "volume smarts" and not just the raw disk piece. Using that utility works as expected, no problems with Node, so anyone needing a workaround could switch to that. It's available as part of the Arsenal Image Mounter project Git repository, but isn't included in the download on the Arsenal web site (that is just the GUI utility). It's parameter-compatible with imdisk so you can just flip the command name/path. Of course, this doesn't affect network shares, sorry.