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

Unable to save file when inotify is in use (using Node) #1956

Open
raphaeltm opened this issue Apr 20, 2017 · 26 comments

Comments

@raphaeltm
Copy link

commented Apr 20, 2017

I'm building a React app using "Create React App." When the development server is running and I try to modify a file, it seems to be locked. My IDE returns an error message. To be clear, I'm running the app in the Windows filesystem /mnt/c/etc....

Your Windows build number:
Microsoft Windows [Version 10.0.15063]

What you're doing and what's happening:
I ran npm run start and everything seems to work properly initially...

What's wrong / what should be happening instead:
The server runs as expected, and given the changes in the Windows Creators Update, I expected the automatic reload to work. Here is what I experience when I try to save a file in JetBrains' WebStorm:

image

I'm not sure how to get more information about the error.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Apr 22, 2017

A couple of days have passed and no one has jumped in on this one. If I had to venture you are looking at a manifestation of #1535 #966 and friends. Keep an eye on 966 and if the status flips to 'better now' try again and see if that helps.

@sunilmut

This comment has been minimized.

Copy link
Member

commented Apr 22, 2017

Adding @JasonLinMS to see if he could help with the iNotify pieces.

@JasonLinMS

This comment has been minimized.

Copy link

commented May 2, 2017

I did try out this scenario in 15063 using Webstorm, and I was able to save files being watched by the server. (See screenshot, the save was successful in a /mnt/c location and the server reloaded.)

We do have a similar issue where files being watched by inotify were unable to be deleted properly, which could be what your editor is doing. This issue was fixed in Insider Build 16184, and we are working towards getting the fix backported into the Creators Update 15063. Is there any chance you can try out the Insider Builds?

image

@stasm

This comment has been minimized.

Copy link

commented Jun 12, 2017

I ran into this exact issue using create-react-app and I think I was able to narrow it down to the scenario when the files are being edited from bash.exe, e.g. using vim. If I edit them with VS Code, everything works fine and the files are watched correctly too. I'm using WIndows 10 1703, compilation 15063.332.

@ptmr-io

This comment has been minimized.

Copy link

commented Oct 18, 2017

Running into this issue with PHPStorm and Webpack --watch. Permission denied when trying to save. Win 10, 1703 Build 15063.674

@KaelWD

This comment has been minimized.

Copy link

commented Oct 22, 2017

I was getting this with webpack watch too, it works if you disable "safe write" in settings:
image
It seems as though WSL has some problems when watched files are deleted from windows.

@ptmr-io

This comment has been minimized.

Copy link

commented Oct 23, 2017

Actually I think it was fixed in 1709 Build 16299.19, at least on my machine using Webpack and PHPStorm

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Oct 23, 2017

The release notes for 16184 say

Fixed issue where deleting DrvFs files with open handles will cause the file to exhibit undefined behavior [GH 544,966,1357,1535,1615]

#1535 was marked as a dupe of #966, although no one has stated explicitly (that I've seen) whether the inotify() problem is the same as the unlink() problem, or whether inotify() is just a mischaracterisation of the root issue. But either way, Jason did say this was addressed back in May, so this issue should probably be duped in with the rest. I think it is safe to say it was never backported to Spring Creators Update, but you should be golden on FCU.

@KaelWD

This comment has been minimized.

Copy link

commented Oct 24, 2017

@ptmr-io I was still on 16299.15, I just updated to .19 and it's still happening.

image

It's still visible in explorer too:
image

But I can't open it;
image

When I kill webpack-dev-server the file disappears:
2017-10-25_02-57-26

Deleting it with rm works just fine on the other hand:
image

@ptmr-io

This comment has been minimized.

Copy link

commented Nov 7, 2017

well, a bit too early. It happens again with webpack --watch and PhpStorm.

@doublemcz

This comment has been minimized.

Copy link

commented Dec 19, 2017

Same issue here. Win 10 - Fall creators update, WebStorm 17.3

@rivaros

This comment has been minimized.

Copy link

commented Jan 19, 2018

Ok, guys. Wake up and look again to this thread.
Using Windows 1709 Build 16299.192 and having same behaviour.
While watching files with inotifywait command

In my case

inotifywait -m -q -r -e CREATE,CLOSE_WRITE,DELETE,MODIFY,MOVED_FROM,MOVED_TO --exclude '___jb_|/\.' --format '%w%f' .

but not relevant occasionally (not always) files get locked, and I cannot do some git merges from Windows, getting error:
Merge: cannot stat 'src/FVS/ClientBundle/Service/Data': Permission denied

@rivaros

This comment has been minimized.

Copy link

commented Jan 19, 2018

After stopping inotifywait evrth goes fine.

@rivaros

This comment has been minimized.

Copy link

commented Jan 19, 2018

And one more - it's ot only in Windows GIT. When running in WSL bash
'git merge origin/master' getting same error, so it happens INSIDE WSL bash

@alexiuscrow

This comment has been minimized.

Copy link

commented Jul 12, 2018

Any progress on this?

@SBRK

This comment has been minimized.

Copy link

commented Aug 28, 2018

Got the same kind of problem with webpack watched files when working on them with Sublime Text or Smartgit. It's the only thing preventing me from using WSL for node dev instead of Powershell...

@SvenZhao

This comment has been minimized.

Copy link

commented Jan 8, 2019

Didn't solve it until now?

@miloshavlicek

This comment has been minimized.

Copy link

commented Jan 20, 2019

Exactly the same issue with Webstorm, Ionic and Ubuntu subsystem. Still no solution?

@tuomastanner

This comment has been minimized.

Copy link

commented Feb 7, 2019

Please could this be prioritized? It seriously breaks / hampers doing any react / webpack web development with WSL.

@xeurun

This comment has been minimized.

Copy link

commented Feb 21, 2019

Any solution? actual problem for fsnotifier in phpstorm

@thernstig

This comment has been minimized.

Copy link

commented May 5, 2019

With the update to VS Code being able to work remotely in WSL, see https://code.visualstudio.com/docs/remote/wsl, there is a high risk there will be an influx of new users bumping into this problem, either creating duplicates or bumping this thread.

It is even listed as a limitation for WSL as can be seen here: https://code.visualstudio.com/docs/remote/wsl#_common-limitations-in-wsl

@PPACI

This comment has been minimized.

Copy link

commented May 10, 2019

Note that this issue should resolve itself with the future WSL2. The embedded kernel should be able to understand the whole set of inotify event, thus resolving this.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2019

Note that this issue should resolve itself with the future WSL2.

In the talk they mentioned they are still "plumbing" inotify(7) into 9P. Which isn't straightforward. It is nontrivial because marshaling fs calls across the wire is usually a one-way request-response kind of thing. The (very old) protocols aren't generally geared toward async notifications. Doable, of course. Just not trivial. Worth observing that the FUSE people have been talking about inotify for at least a decade.

You can observe this in WSL1 Insiders right now. Open a file on \\wsl$ with VS Code. Edit it on the WSL side with nano, save. No automagic update on the Windows side. No one has reported this yet, natch. I suspect you will see this in the WSL->win32 direction too in WSL2 at least initially.

Solution proposed is to use VS Code Remote on WSL2/ext4. Which solves everything. Except JetBrains.

@andreialecu

This comment has been minimized.

Copy link

commented May 10, 2019

@therealkenc This timestamp in the video you linked: https://youtu.be/lwhMThePdIo?t=2189 seems to show automagic refresh on the Windows side of the file being created from the linux side, so there is some notification happening. This is on NTFS.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2019

show automagic refresh on the Windows side of the file being created from the linux side

Yeah, but Windows Explorer polls the folder you see on the screen. They didn't edit the file in vi while VS Code was running. I probably would have showed off that working, because of the pure awesomeness of it working (and for the crowd gasp).

That said, I should avoid predictions ("I suspect...."), and you make a valid point. I didn't mean to imply skepticism, just that it is a tough problem. It could be that they have been working hard on all of this. This goes for AF_UNIX sockets too; another tough problem.

@AddoSolutions

This comment has been minimized.

Copy link

commented May 14, 2019

I was getting this with webpack watch too, it works if you disable "safe write" in settings:
image
It seems as though WSL has some problems when watched files are deleted from windows.

This saved me a TON of digging, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.