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

[raphaeltm]

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:

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

[therealkenc]

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]

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

[JasonLinMS]

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?

[stasm]

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.

[ptmrio]

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

[KaelWD]

I was getting this with webpack watch too, it works if you disable "safe write" in settings:

It seems as though WSL has some problems when watched files are deleted from windows.

[ptmrio]

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

[therealkenc]

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]

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

It's still visible in explorer too:

But I can't open it;

When I kill webpack-dev-server the file disappears:

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

[ptmrio]

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

[doublemcz]

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

[rivaros]

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]

After stopping inotifywait evrth goes fine.

[rivaros]

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]

Any progress on this?

[SBRK]

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]

Didn't solve it until now?

[miloshavlicek]

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

[tuomastanner]

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

[xeurun]

Any solution? actual problem for fsnotifier in phpstorm

[thernstig]

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]

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]

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]

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

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]

I was getting this with webpack watch too, it works if you disable "safe write" in settings:

It seems as though WSL has some problems when watched files are deleted from windows.

This saved me a TON of digging, thank you!

[alshdavid]

I am using WSL2 and getting this issue

[Ibsardar]

I am using WSL2 and getting this issue

Me too

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!