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 #6861 (comment) 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]

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.

[heavenkiller2018]

i have the same problem when use imdisk

[rekna1]

still have this problem on RAM disk , with version v14.17.5 (from eslint in vscode)

[DavraYoung]

Still the same problem when using Node v16.4.2 Rollup package on imDisk RamDisk