Yarn: Windows gets unlink error when running yarn while an executable is running

[adamk33n3r]

Do you want to request a feature or report a bug?
bug

What is the current behavior?
When running yarn while nodemon is running I get EPERM: operation not permitted, unlink 'C:\\cygwin\\home\\Adam\\projects\\newyoc\\server\\node_modules\\.bin\\nodemon'. This causes the files in node_modules/.bin to become non executable. This forces me to quit all running processes every time I want to run yarn which is a big hit to productivity.
This doesn't happen on linux.

If the current behavior is a bug, please provide the steps to reproduce.

1. Be on windows
2. Install nodemon
3. Run nodemon
4. Run yarn

What is the expected behavior?
No error

Please mention your node.js, yarn and operating system version.
Node: v6.9.5
Yarn: 0.19.1
OS: Windows 10

[whitecolor]

For me this happens when I run bin executable in WSL. after this have to reinstall package to restore bins.

I think yarn should not so aggressively try to unlink/link again bins.

cc @bestander

[bestander]

The code is here https://github.com/yarnpkg/yarn/blob/master/src/package-linker.js#L36.
I wonder if it is related to how fs.symlink is working on windows.
Maybe it should check if symlink exists and points to the same location first?

This looks like a great opportunity to send a PR.

[whitecolor]

The problem is that file in .bin may be locked and yarn aggressively trying to clean up node_modules before installing, in this case can not unlink/remove .bin: https://github.com/yarnpkg/yarn/blob/master/src/package-linker.js#L264

But I'm not sure if it is correct to exclude .bin folder from this list, and after this yarn tries to read this link can is not able too.

So the problem is in locking of file from removal/replacement.

[bestander]

package-linker removes symlinks form possibleExtraneous https://github.com/yarnpkg/yarn/blob/master/src/package-linker.js#L215

[whitecolor]

Yes I see this, to solve this there may be required more complex logic of removal of .bin folder, not whole folder but file by file, handling exception, becase file is still removed and though an exception is thown.

The workaround for the issue is not to use .bin scripts for long running (watching) tasks but replace them with direct location for example node_modules/typescript/bin/tsc instead of just tsc

[bestander]

Well, modifying node_modules folder while the Node app is running is quite
non deterministic anyway.
So maybe we can't do much about it.

On 9 May 2017 at 15:48, Alex [e-mail] wrote:

Yes I see this, to solve this there may be required more complex logic of
removal of .bin folder, not whole folder but file by file, handling
exception, becase file is still removed and though an exception is thown.

The workaround for the issue is not use .bin scripts for long running
(watching) tasks but replace them with direct location for example node
node_modules/typescript/bin/tsc instead of just tsc

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/2685#issuecomment-300188940, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWHDfCUE7S-XzellRBdjt5AQ1b0r4ks5r4HzSgaJpZM4L-qCh
.

[whitecolor]

Well, modifying node_modules folder while the Node app is running is quite

Usual case in development, who stops all the services to add/upgrade each new dependency? Usually watching utilities can handle those changes.

[bestander]

Yeah, it can be common.
The problem is that yarn may rebuild the node_modules when you add/upgrade
a dependency because it guarantees deterministic folder structure.
But I support that symlinks in .bin folder should not be removed if they
don't change.

On 9 May 2017 at 16:19, Alex [e-mail] wrote:

Well, modifying node_modules folder while the Node app is running is quite

Usual case in development, who stops all the services to add/upgrade each
new dependency? Usually watching utilities can handle those changes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/2685#issuecomment-300198518, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWAdhBnP-kSP5RHAkwLF8hF0NBb8jks5r4IP-gaJpZM4L-qCh
.

[whitecolor]

But I support that symlinks in .bin folder should not be removed if they
don't change.

There are actually no symlinks in .bin there are just executable scripts that run some scripts in node_modules, yarn tries to remove .bin folder and recreate it again on each install operation, and fails if any of containing scripts happens to be locked, though it actually removes the locked file that causes the exception, so potentially it could just handle this exception, though it would require some additional logic.

[bestander]

Thanks for investigating more.
What would it take to make Yarn smarter and not delete those if they don't
change?

On Wed, 10 May 2017 at 12:43, Alex [e-mail] wrote:

But I support that symlinks in .bin folder should not be removed if they
don't change.

There are actually no symlinks in .bin there are just executable scripts
that run some scripts in node_modules, yarn tries to remove .bin folder
and recreate it again on each install operation, and fails if any of
containing scripts happens to be locked, though it actually removes the
locked file that causes the exception, so potentially it could just handle
this exception, though it would require some additional logic.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/2685#issuecomment-300457059, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWP2vMdWGDyF_OYF2pSF1I7kMy4_9ks5r4aL2gaJpZM4L-qCh
.

[whitecolor]

Yes it could compare the content of existing file in .bin.

[bestander]

@whitecolor, should we expect a PR? :)

[BYK]

I don't think this is a bug since trying to delete files that are in use will always cause an error on Windows and it will be okay on Linux (that's why you can do rm -rf / and actually delete everything eventually.

That being said, I think it would be a nice improvement to recover from this so tagged this as a feature. PRs welcome. Shouldn't be too hard :)

[samayo]

Can someone fix this issue already? This is definitely a bug imho

[bestander]

@samayo, everyone is waiting for you to submit a PR :)

[Haykinz]

I experienced this today and i had to close down all development and restart again, awaiting permanent fix to this too

[whitecolor]

@Haykinz awaiting PR from you too 😄

[bugproof]

Same issue here. I don't know exactly if it's caused by nodemon (because I never used it) but I had a auto-reload watcher running using one of the build systems for the web.

[Ciantic]

Does anyone have a clue how to fix this? Would it be enough to try to unlink in a loop (waiting few seconds between tries)?

The parcel's development server is nearly useless in Windows cause it fails with unlink errors all the time.

[sinyang]

A temporary workaround for this could be to kill the process that's running flow.exe.

I exclusively use the Ubuntu WSL in windows. However, my IDE, Intellij, uses windows CMD to execute tasks, such as running the Flow server. So I've ran into this unlink error a couple of times, having to shut down my PC to resolve it in the past.

However, today after finding the flow.exe process id and killing it, I was able to use yarn with no issue.

# find the process id

tasklist /fi "imagename eq flow.exe"

# You should see something like the table below. My Intellij starts many flow servers from some reason. Dunno if thats normal.

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
flow.exe                     99616 Console                    1     16,292 K
flow.exe                     94932 Console                    1    110,176 K
flow.exe                     89472 Console                    1     24,464 K
flow.exe                    101328 Console                    1     20,272 K
flow.exe                    101460 Console                    1     20,360 K
flow.exe                     55260 Console                    1     20,284 K
flow.exe                     55692 Console                    1     20,304 K
flow.exe                    101524 Console                    1     20,320 K
flow.exe                     90504 Console                    1     20,308 K
flow.exe                     55804 Console                    1     20,296 K
flow.exe                     17908 Console                    1         52 K


# Grab a PID and kill each process. Windows will return a success message if it was able to kill the process.
# Note that the "/F" is to forcefully kill it. 

taskkill /pid 99616 /F

# You'll what to do this for each PID in the table

[GlenHughes]

This happened to me as I had a Gatsby develop instance running and it tried to delete the file while it was in use. Just close the current process in the terminal and try again :)

[Badlapje]

anyone getting this in phpstorm: close and restart if it keeps failing, that solves the issue

[nathcs]

I don't know if anyone fixed but I closed the application (VSCode) and started as admin.
It solved my problem.

[akomm]

When I got the error, without searching, I knew its the running process/lock inside .bin & yarn rebuilding the .bin that is the issue. Checked if there is an issue already, and here we go :)

OT:
Working 99% of the time on linux. For years. Then work 10 minutes on windows and the issue chain starts. Not due to it being different for a logical reason, but pure stupidly: Locking a file which has been loaded in memory and is not needed for the process is one of many stupid design choices with this pathetic OS. Hey, but you can fix many problems by just running it as admin ...

[MichalCzerwonka]

I solved this problem by removing node_modules directory and install again.

[Vuyisanani]

Hi I also experienced the issue, and my workaround on it was to stop the server, installed nodemom, installed typecript and the re-installed firebase, am on windows 10 and am using yarn: see commands I ran below:
$yarn add nodemon
$yarn add -g typescript
then my issue was when I was installing firebase dependencies, but now re-ran the following command which worked just fine
$yarn add firebase angularfire2 --save

[StevePavlin]

Solved this by killing all docker containers. One of the volumes mounted must of been holding a lock on the yarn folder 😎

docker kill $(docker ps -q)

[ryancwalsh]

I had already tried running Git Bash and PowerShell as Admin, so those tips didn't help.

Closing Visual Studio Code didn't help either.

What finally worked for me was exiting a process that I had running in another Git Bash window:
yarn rw dev (for RedwoodJs).

Once that was no longer running, yarn workspace web add react-select worked in PowerShell as Admin.

[Chappie74]

Solved this by killing all docker containers. One of the volumes mounted must of been holding a lock on the yarn folder 😎

docker kill $(docker ps -q)

this worked for me. I had my frontend folder hooked up as a volume to a docker container. Stopping the container, then installing the module i wanted to, then restarting container worked.

[MrDrummer]

Does anyone know if using https://github.com/coreybutler/nvm-windows could be a cause for this issue?