-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Comments
In Node.js v6, the 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. |
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? |
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 |
@sethdorris This looks like something is up with your directory structure. Can you run other |
@sethdorris Out of curiosity, is |
@mscdex, yes I am on a work machine, so it is a mounted drive |
There have been no changes to
That's weird, it complains about that path being a directory?! What happens if you run |
@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) |
@saghul, sorry I am not an expert with node, how do I run fs.statSync on my server.js? |
|
|
Not a Windows person but that looks fine to me, @sethdorris Does |
@addaleax the first command outputs the same as the node -pe I ran earlier... realpathSync fails with same error as my first post. |
@sethdorris Which one of
is the first to fail? |
I can't get any output ...
it just stays on |
.. I just pulled the repo from my mac and ran the server with Node and the application successfully launched.. no issues. |
Eh, sorry, you may have to switch |
|
@sethdorris Are you sure there’s nothing special about your U: drive? Does this work with other drives, e.g. C:? |
@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? |
I think @jasnell explained why this changed in #6861 (comment) quite well… basically, the underlying implementation of /cc @nodejs/platform-windows |
Is that something that will need to be fixed, or is it just known not to try to work on projects on virtual drives? |
I think it’s something that needs to be fixed, but probably rather in libuv than in Node.js… @saghul? |
@sethdorris I can’t reproduce this with a simple virtual drive. Can you provide information on how this drive has been created? |
Can you provice the simplest possible way to reproduce this? |
@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. |
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. :) |
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 In my testing, |
@derekstavis Thanks, that should make it easy to reproduce. |
@fzzzt I could reproduce it with imdisk. Let's see if I can come up with a fix. |
After talking with the |
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
i have the same problem when use imdisk |
still have this problem on RAM disk , with version v14.17.5 (from eslint in vscode) |
Still the same problem when using Node v16.4.2 Rollup package on imDisk RamDisk |
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
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
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
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
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
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.
The text was updated successfully, but these errors were encountered: