Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
sethdorris opened this issue May 18, 2016 · 39 comments
Closed

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

sethdorris opened this issue May 18, 2016 · 39 comments
Labels
fs Issues and PRs related to the fs subsystem / file system. libuv Issues and PRs related to the libuv dependency or the uv binding. windows Issues and PRs related to the Windows platform.

Comments

@sethdorris
Copy link

sethdorris commented May 18, 2016

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
@addaleax addaleax added the fs Issues and PRs related to the fs subsystem / file system. label May 18, 2016
@jasnell
Copy link
Member

jasnell commented May 18, 2016

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
Copy link
Member

jasnell commented May 18, 2016

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
Copy link
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

@addaleax
Copy link
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?

@mscdex
Copy link
Contributor

mscdex commented May 18, 2016

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

@sethdorris
Copy link
Author

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

@saghul
Copy link
Member

saghul commented May 18, 2016

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
Copy link
Member

jasnell commented May 18, 2016

@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
Copy link
Author

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

@mscdex
Copy link
Contributor

mscdex commented May 18, 2016

@sethdorris

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

@sethdorris
Copy link
Author

sethdorris commented May 18, 2016

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

@sethdorris
Copy link
Author

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

realpathSync fails with same error as my first post.

@addaleax
Copy link
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?

@sethdorris
Copy link
Author

sethdorris commented May 18, 2016

@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
Copy link
Author

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

@addaleax
Copy link
Member

addaleax commented May 18, 2016

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

@sethdorris
Copy link
Author

sethdorris commented May 18, 2016

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
Copy link
Member

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

@sethdorris
Copy link
Author

@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 addaleax added the windows Issues and PRs related to the Windows platform. label May 18, 2016
@addaleax
Copy link
Member

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
Copy link
Author

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 addaleax added the libuv Issues and PRs related to the libuv dependency or the uv binding. label May 18, 2016
@addaleax
Copy link
Member

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

@addaleax
Copy link
Member

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

@saghul
Copy link
Member

saghul commented May 18, 2016

Can you provice the simplest possible way to reproduce this?

@sethdorris
Copy link
Author

sethdorris commented May 19, 2016

@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
Copy link

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
Copy link

derekstavis commented Jun 24, 2016

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:

screen shot 2016-06-24 at 4 03 46 pm

@saghul
Copy link
Member

saghul commented Jun 25, 2016

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

@saghul
Copy link
Member

saghul commented Jul 13, 2016

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

@josh-endries
Copy link

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.

bzoz added a commit to JaneaSystems/node that referenced this issue Aug 5, 2016
This reverts parts of nodejs@b488b19
restoring javascript implementation of realpath and realpathSync.

Fixes: nodejs#7175
Fixes: nodejs#6861
Fixes: nodejs#7294
Fixes: nodejs#7192
Fixes: nodejs#7044
Fixes: nodejs#6624
Fixes: nodejs#6978
@bzoz bzoz closed this as completed in 08996fd Aug 12, 2016
cjihrig pushed a commit that referenced this issue Aug 15, 2016
This reverts parts of b488b19
restoring javascript implementation of realpath and realpathSync.

Fixes: #7175
Fixes: #6861
Fixes: #7294
Fixes: #7192
Fixes: #7044
Fixes: #6624
Fixes: #6978
PR-URL: #7899
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@heavenkiller2018
Copy link

i have the same problem when use imdisk

@rekna1
Copy link

rekna1 commented Aug 23, 2021

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

@DavraYoung
Copy link

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

alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Jun 9, 2022
Windows is IO bound which causes tests to take signifintly longer than Linux.

With this change we introduce the use of RAM disk on Windows instead of a physical disk to store tests projects files which reduces this overhead.

While Circle CI docs mention to use `ImDisk` https://support.circleci.com/hc/en-us/articles/4411520952091-Create-a-windows-RAM-disk, we use a different tool Arsenal Image Mounter `aim_ll` due to following Node.js issue: nodejs/node#6861

The `aim_ll` CLI is based on `ImDisk` and is parameter compatible.

From testing a full run of the Windows E2E full test suit goes from ~56min to ~35mins

With RAM disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23286/workflows/4b1dc425-f7ed-49d6-aeba-b2c503d08756/jobs/309423/parallel-runs/2?filterBy=ALL

Without RAM Disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23256/workflows/3f551c3c-fbb0-445f-80f9-1801d4adc664/jobs/309312
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Jun 9, 2022
Windows is IO bound which causes tests to take signifintly longer than Linux.

With this change we introduce the use of RAM disk on Windows instead of a physical disk to store tests projects files which reduces this overhead.

While Circle CI docs mention to use `ImDisk` https://support.circleci.com/hc/en-us/articles/4411520952091-Create-a-windows-RAM-disk, we use a different tool Arsenal Image Mounter `aim_ll` due to following Node.js issue: nodejs/node#6861

The `aim_ll` CLI is based on `ImDisk` and is parameter compatible.

From testing a full run of the Windows E2E full test suit goes from ~56min to ~35mins

With RAM disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23286/workflows/4b1dc425-f7ed-49d6-aeba-b2c503d08756/jobs/309423/parallel-runs/2?filterBy=ALL

Without RAM Disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23256/workflows/3f551c3c-fbb0-445f-80f9-1801d4adc664/jobs/309312
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Jun 9, 2022
Windows is IO bound which causes tests to take significantly longer than Linux.

With this change we introduce the use of RAM disk on Windows instead of a physical disk to store tests projects files which reduces this overhead.

While Circle CI docs mention to use `ImDisk` https://support.circleci.com/hc/en-us/articles/4411520952091-Create-a-windows-RAM-disk, we use a different tool Arsenal Image Mounter `aim_ll` due to following Node.js issue: nodejs/node#6861

The `aim_ll` CLI is based on `ImDisk` and is parameter compatible.

From testing a full run of the Windows E2E full test suit goes from ~56min to ~35mins

With RAM disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23286/workflows/4b1dc425-f7ed-49d6-aeba-b2c503d08756/jobs/309423/parallel-runs/2?filterBy=ALL

Without RAM Disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23256/workflows/3f551c3c-fbb0-445f-80f9-1801d4adc664/jobs/309312
alan-agius4 added a commit to alan-agius4/angular-cli that referenced this issue Jun 9, 2022
Windows is IO bound which causes tests to take significantly longer than Linux.

With this change we introduce the use of RAM disk on Windows instead of a physical disk to store tests projects files which reduces this overhead.

While Circle CI docs mention to use `ImDisk` https://support.circleci.com/hc/en-us/articles/4411520952091-Create-a-windows-RAM-disk, we use a different tool Arsenal Image Mounter `aim_ll` due to following Node.js issue: nodejs/node#6861

The `aim_ll` CLI is based on `ImDisk` and is parameter compatible.

From testing a full run of the Windows E2E full test suit goes from ~56min to ~35mins

With RAM disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23286/workflows/4b1dc425-f7ed-49d6-aeba-b2c503d08756/jobs/309423/parallel-runs/2?filterBy=ALL

Without RAM Disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23256/workflows/3f551c3c-fbb0-445f-80f9-1801d4adc664/jobs/309312
alan-agius4 added a commit to angular/angular-cli that referenced this issue Jun 13, 2022
Windows is IO bound which causes tests to take significantly longer than Linux.

With this change we introduce the use of RAM disk on Windows instead of a physical disk to store tests projects files which reduces this overhead.

While Circle CI docs mention to use `ImDisk` https://support.circleci.com/hc/en-us/articles/4411520952091-Create-a-windows-RAM-disk, we use a different tool Arsenal Image Mounter `aim_ll` due to following Node.js issue: nodejs/node#6861

The `aim_ll` CLI is based on `ImDisk` and is parameter compatible.

From testing a full run of the Windows E2E full test suit goes from ~56min to ~35mins

With RAM disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23286/workflows/4b1dc425-f7ed-49d6-aeba-b2c503d08756/jobs/309423/parallel-runs/2?filterBy=ALL

Without RAM Disk
https://app.circleci.com/pipelines/github/angular/angular-cli/23256/workflows/3f551c3c-fbb0-445f-80f9-1801d4adc664/jobs/309312
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system. libuv Issues and PRs related to the libuv dependency or the uv binding. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

No branches or pull requests