Skip to content

Error: EISDIR illegal operation on directory - Binding.realpath #6861

Description

@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

Activity

  1. added
    fsIssues and PRs related to file-system APIs and the fs module.
    on May 18, 2016
  2. jasnell commented on May 18, 2016

    @jasnell
    Member

    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.

  3. jasnell commented on May 18, 2016

    @jasnell
    Member

    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?

  4. sethdorris commented on May 18, 2016

    @sethdorris
    Author

    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

  5. addaleax commented on May 18, 2016

    @addaleax
    Member

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

  6. mscdex commented on May 18, 2016

    @mscdex
    Contributor

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

  7. sethdorris commented on May 18, 2016

    @sethdorris
    Author

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

  8. saghul commented on May 18, 2016

    @saghul
    Member

    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?

  9. jasnell commented on May 18, 2016

    @jasnell
    Member

    @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)

  10. sethdorris commented on May 18, 2016

    @sethdorris
    Author

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

  11. mscdex commented on May 18, 2016

    @mscdex
    Contributor

    @sethdorris

    node -pe "require('fs').statSync('U:\\Desktop\\chatapp\\build\\server\\server.js')"
    
  12. sethdorris commented on May 18, 2016

    @sethdorris
    Author

    @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>
    
  13. addaleax commented on May 18, 2016

    @addaleax
    Member

    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?

  14. sethdorris commented on May 18, 2016

    @sethdorris
    Author

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

    realpathSync fails with same error as my first post.

  15. addaleax commented on May 18, 2016

    @addaleax
    Member

    @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?

  16. 23 remaining items

  17. josh-endries commented on Jul 16, 2016

    @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.

  18. heavenkiller2018 commented on Dec 18, 2020

    @heavenkiller2018

    i have the same problem when use imdisk

  19. rekna1 commented on Aug 23, 2021

    @rekna1

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

  20. DavraYoung commented on Apr 5, 2022

    @DavraYoung

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fsIssues and PRs related to file-system APIs and the fs module.libuvIssues and PRs related to the libuv dependency or the uv binding.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions