Open Philipp91 opened 3 years ago
Can you provide structure of your project?
See here. I can additionally provide my own setup, but it would take quite a while to strip it down to something that can be posted on GitHub.
@Philipp91 Yep, please try to provide, and I will investigate this problem, I think something wrong in plugins/loaders/webpack-dev-server, because we are warning /mnt/
and it should not happens
# Use WSL 1
cd /mnt/c/Users/....
mkdir watchpack-reproduce
cd watchpack-reproduce
npm init -y && npm install webpack webpack-cli --save-dev
mkdir src
echo Test > index.html
echo 'console.log(window)' > src/index.js
NODE_ENV=development webpack --watch --watch-options-stdin
# Now the 4 errors posted above appear.
compilation.fileDependencies
contains:
[
'/mnt/c/Users/Philipp/repos/watchpack-reproduce/package.json',
'/mnt/c/Users/Philipp/repos/watchpack-reproduce/src',
'/mnt/c/Users/Philipp/repos/watchpack-reproduce/src/index.js',
'/mnt/c/Users/Philipp/repos/watchpack-reproduce',
'/mnt/c/Users/Philipp/repos',
'/mnt/c/Users/Philipp',
'/mnt/c/Users',
'/mnt/c',
'/mnt',
'/'
]
This may be a new behavior in webpack v5. Is it okay for webpack to tell watchpack to watch all those directories up to the root?
What is cwd
when you run NODE_ENV=development webpack --watch --watch-options-stdin
?
It's /mnt/c/Users/Philipp/repos/watchpack-reproduce
, I ran it quite exactly as posted above.
It's normal that these directories are watched. The relevant entry is /mnt/c/Users
which is watched because the Users
directory could theoretically change to a symlink to some different location. Watchpack always watches to complete directory instead of single files for performance reasons.
So the errors are actually irrelevant for watching these the Users
directory. It would probably make sense to ignore them internally until these files are actually watched.
Okay that makes sense. I find it a bit complex to implement due to the series of DirectoryWatcher
instances. Now the instance with path="/mnt/c"
needs to know that it should suppress all (?) kinds of errors for all (?) files except the /mnt/c/Users
subdirectory (which this particular watcher instance doesn't know about, or at least doesn't that it's special).
which this particular watcher instance doesn't know about
Each instances knows which files are watched on this instance. So there is a /mnt/c
instance where only Users
is watched. Suppressing the warnings is probably the easy part. More tricky is that someone might start watching hiberfil.sys
at a later time. In this case we need to show the warning at this later time.
FWIW I found this thread after running into the same error on Arch Linux. I use pCloud which puts a fuse mount in my home directory and was getting Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/home/whoops/pCloudDrive'
. Needless to say, my project isn't in that directory and has no dependency on it. After reading this thread and confirming with some console.log
s sure enough WatchPack was trying to lstat
that mount point when watching my home directory.
I'm also not sure why it was getting permission denied when it tried, but it was certainly confusing and sent me down some rabbit holes trying to figure out what I misconfigured to make it even try.
What terminal do you use? I have Windows and I am having the same issue with wsl. Try to use cmd instead. It worked for me. Good luck.
I am having the same problem. I am in a process of migrating from Gatsby v2 to v3. As far as i understand, this has something to do with WSL2. I just hope that Gatsby team will not forget this issue.
Also running into this. My watch options are only ignoring node_modules so I'm not sure why this would be happening.
Plus one running into the same issue with WSL2 + Windows 10. I have root mounted as / in WSL, so:
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/DumpStack.log.tmp' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/hiberfil.sys' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/pagefile.sys' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/c/swapfile.sys'
Plus another, also with WSL2 + Windows 10
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'
Well i also run into the same error. Running windows 10 x64 bit
Watchpack Error (initial scan): Error: UNKNOWN: unknown error, lstat 'C:\$360Section'
C:$360Section
interesting, can you provide path on your project?
js
const path = require("path");
// webpack config
module.exports = {
// partner area main app entry for
entry: {
"App.bspa": "./App.bspa.js",
"App.Admin": "./App.Admin.js",
},
output: {
filename: "[name].min.js",
path: path.resolve(__dirname, "www/dist"),
},
mode: "development",
watch: true,
devtool: "eval-source-map",
watchOptions: {
ignored: ["**/node_modules"],
poll: 1000,
aggregateTimeout: 100,
},
module: {
rules: [
{
test: /\.css$/i,
use: ["style-loader", "css-loader"],
},
{
test: /\.(png|svg|jpg|jpeg|gif)$/i,
type: "asset/resource",
},
{
test: /\.(woff|woff2|eot|ttf|otf)$/i,
type: "asset/resource",
},
],
},
};
C:$360Section
looks like 360 total security dir
@obipascal I mean path to the project, i.e. C:\\path\to\project
and version of WSL
C:\Servers\xampp\htdocs\www\bitmoservice\public
this is the structure of the project dir
I have this issue on WSL2 path to project: /mnt/c/Users/username/Documents/Projects/gatsby-blog
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'
Can reproduce like this
gatsby new my-blog-starter https://github.com/gatsbyjs/gatsby-starter-blog
cd my-blog-starter
gatsby develop
I kind of wonder what watchpack is doing with swapfile.sys or through which part. Not sure if this help or not, but I started hacking react with 'babel' & 'live-server' running manually via command-line. This works fine.
As the course progress, the instructor introduced webpack, and hence, this problem!
So the errors are actually irrelevant for watching these the Users directory. It would probably make sense to ignore them internally until these files are actually watched.
@sokra It seems like you had a particular workaround in mind. It would be great if you could implement and release that. As you say, the errors are harmless. But they don't look like that, and in the face of any (unrelated) issues with Webpack, people will waste lots of time investigating them, and some of the end up here and even take the time to post screenshots and repro-instructions here, which shows how much time they've previously spent on debugging. We should save that time by suppressing the errors.
/cc @sokra
Same here: WSL 2, win 10
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/d/DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/d/pagefile.sys'
Same here: WSL 2, win 10
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/d/DumpStack.log.tmp' Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/d/pagefile.sys'
I get this as well in windows 10 wsl 2, after converting to gatsby 3 in my project
Okay, finally fixed it. The problem is with the path as already someone said. Your project should not be located at /mnt/d/...
or somewhere on your windows machine. Instead just make sure you have did this:
cd ~
your path here should be like user@user
which means /home/user/
in linuxAs @lightmyfire17 said, you should be working in the /home/user/ folder if you are using WSL 2. Windows recommends that and it solves the issue.
You can read more here: https://docs.microsoft.com/en-us/windows/wsl/compare-versions under Performance across OS file systems
I get the same errors on WSL2, and I have my files in c:/users/myname/React. I have been using Webpack-dev-server for ages, and now it breaks. Anyone have any answers?
I had a similar issue with Windows 10 and WSL 2, moving the project to the Ubuntu filesystem fixed it for me.
This is also recommended from Microsoft as stated above.
We recommend against working across operating systems with your files, unless you have a specific reason for doing so. For the fastest performance speed, store your files in the WSL file system if you are working in a Linux command line (Ubuntu, OpenSUSE, etc). If you're working in a Windows command line (PowerShell, Command Prompt), store your files in the Windows file system.
So if you have your files in C:\Users\YourName\workspace\your-project
just move it to \\wsl$\Ubuntu\home\YourName\workspace\your-project
and you should be fine. The files can still be accessed comfortably from Windows, especially if you create a bookmark to \\wsl$\Ubuntu
in Quick Access. To be sure nothing odd happens I did not copy package-lock.json and node_modules and did a fresh npm install
after copying.
Note: The folder workspace
is just what I personally use as a container for my projects. You can also move the project to any other folder in the Ubuntu filesystem, preferrably someting in you home directory of course.
The downside, though, is that PHPStorm now is complaining about the network mount, but I did not feel any big difference yet:
Maybe running PHPStorm native in Ubuntu using WSLg would be a viable solution for this issue in the Future.
PhpStorm complains that it can't watch the files. What this might mean is that, after commands like git checkout
or npm install
it won't show the latest state in the file system.
Besides that, I'm not even using WSL2 myself because cross-OS file system performance is worse. With WSL1 that's not the case, but it also means that I can't keep my files in \\wsl$\...
. With WSL2, I would have to decide between fast npm
and fast PhpStorm, but can't have both. (Unless PhpStorm were on Ubuntu as well, as you said. Not sure if / how well that would work.)
Ok, I tried putting my file in \wsl$\Ubuntu\home\YourName\Your-project. There is no workspace directory. So I just put my project in YourName. I see it in my Windows file explorer. But I cant access it on the command line?
@gadgetcrawford On the ubuntu command line that path would be /home/YourName/
.
The downside, though, is that PHPStorm now is complaining about the network mount, but I did not feel any big difference yet
After working a little bit more with this setup I do feel a difference, it’s not ideal. Sometimes syntax highlighting takes a long time to take effect.
I think we can ignore (on code level, so you will not see them) these warning, i.e. all above context
So for some incredibly rare arbitrary use-case of someone potentially at some point having a minor issue because they might replace a directory with a link at some point, you now watch all the paths above the context and thus cause issues to everyone else except this approx. 0.0001% of potential users?
Maybe do the exact opposite and let that 0.0001% fix the problems they cause by themselves and let everyone else have a functioning system that doesn't unnecessarily watch for all changes in all their parent directories?
Should I address the same issue? Please refer to all information about my system as system information report file that is created following instructions here:
System info reference at nvidia site (also I had to rename it systemInfo.nfo -> systemInfo.txt since this editor does not allow nfo type, so please manually rename it back if you wish windows to identify application to open this type of file correctly)
Also here is console output from my windows WSL ubuntu zsh terminal(please do not pay attention to compilation errors it is not important for our case, what is important is last 4 lines npmWatchTerminalOutput.txt
As @lightmyfire17 said, you should be working in the /home/user/ folder if you are using WSL 2. Windows recommends that and it solves the issue.
You can read more here: https://docs.microsoft.com/en-us/windows/wsl/compare-versions under Performance across OS file systems
I had been using mnt/c/repos/myapp/
and when I switched to /home/{User}/repos/myapp
, not only did the error go away with files but the compile time improved substantially.
Aside from the dangers of have to operating systems having access to the same files, the performance benefit is worth noting.
Just do what I did. I completely removed Windows, replaced it with Linux. No more WSL, no more Microsoft. I am able to solve most issues, but WSL is not true Linux. Life is so much easier now. As for Lieutu, It isn't so arbitrary. You should get your facts straight before you add your input.
This was happening to me. I am using WSL2 and on Windows I have the GUI program Github Desktop installed. Because it likes managing the repo, I had just symlinked it to my WSL2 directory.
To reproduce open up the Terminal which starts in the WSL2 context (I am using WIndows Terminal from the App Store) You will be as stated in the OS context you installed (Ubuntu, Kali, etc...)
ln -fs /mnt/c/Users/cjensen/Documents/GitHub/my_repo ~/projects/
cd ~/projects/my_repo
npm install
npm run dev
That is where I get the error
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'
I don't know even after reading the above why WebPack is interested in the above files, but in my case unlinking the symlink and moving the entire project to my WSL2 Linux directory worked.
cd ~/projects/
unlink ./my_repo
cp -rf /mnt/c/Users/cjensen/Documents/GitHub/my_repo ~/projects
cd ~/projects/my_repo
npm run dev
No longer getting error/warning message. Maybe that will help anyone else.
It happens with me, but on Linux (Ubuntu), trying to run Gatsby.
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/media/bitlocker'
This path /media/bitlocker
is not accessible to the user and its ok, but watchpack is trying to access it idk why because the project is on another path: /media/data/workspace/project
.
Gatsby CLI version: 3.6.0 Gatsby version: 3.4.1 Node version: v12.22.1
I got the same error too
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/DumpStack.log.tmp'
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/hiberfil.sys'
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/pagefile.sys'
ERROR
Watchpack Error (initial scan): Error: EACCES: permission denied, lstat '/mnt/c/swapfile.sys'
Just followed the Gatsby tutorial guide @ https://www.gatsbyjs.com/docs/tutorial/part-1/
Okay, finally fixed it. The problem is with the path as already someone said. Your project should not be located at
/mnt/d/...
or somewhere on your windows machine. Instead just make sure you have did this:
cd ~
your path here should be likeuser@user
which means/home/user/
in linux- now make git clone/set up project manually
I wish I understood this better.
I am having the same issue. Some odd specifics are that:..... windows 10 VS Code recently updated Ubuntu 20 with user name dac User on windows machine dav
It works without issues on my machine at work, however, I was married recently and changed my last name so I made an ubuntu account to reflect that while my windows machine does not have the updated user name. The bundle.js
still lands where it needs to and is working, however, the errors are obviously less than optimal.
So for some incredibly rare arbitrary use-case of someone potentially at some point having a minor issue because they might replace a directory with a link at some point, you now watch all the paths above the context and thus cause issues to everyone else except this approx. 0.0001% of potential users?
Maybe do the exact opposite and let that 0.0001% fix the problems they cause by themselves and let everyone else have a functioning system that doesn't unnecessarily watch for all changes in all their parent directories?
Your lack of empathy makes sense until a patron is hit with the realization that this is a thread meant for supporting users.
So I kinda have things working. So npm run watch
is working! However, it is because I navigated by doing cd ~
git clone <repo>
npm install
npm run watch
however I can't access the location of this file via VS code. For the record, my name on my computer is different from Ubuntu cause I got married, and changed my last name which I crescendoed in my Ubuntu setup. So my windows has ...\user\dboyea
while ubuntu looks like dacruz@Desktop-5LULQUN
@dbooyah93 is there any fix for this issue?
For many people "simply" moving project is impossible due to various reasons. I also don't quite understand why any program would go through whole directory listing, this is literally something that is against unix way - users don't expect project watcher to iterate through whole hierarchy to list and watch every ancestor.
I can put it in the following way: does anyone even expect this behavior? It is counter-intuitive
@nick4fake I am a fairly new developer so I can't speak to what makes sense and what doesn't. The best I could do is in my VS Code terminal (Ubuntu 20) navigate to ~
then git clone <repo>
then npm install
and npm run watch
.
The two problems with this is 1) navigating to this directory seems impossible for VS Code from the "File > Open Folder" option, and 2) updating that directory would require a git push
from the folder VS Code CAN access which is mnt\c\user\dbooyah93....
then git pull
from the terminal in that hidden wsl directory.
The two issues kinda relate back to the same "solution" which is to just run npm run build
every time I do an update which takes what feels like an eternity but is at least fewer steps than what I would do to have npm run watch
work.
I just can't navigate to the wsl directory hidden under ~
. I'm thinking I could link this directory to a more easily accessible one, but I don't know at the moment.
I run
webpack --watch --watch-options-stdin ...
and amidst its initial build (not the subsequent builds triggered by changed files), it prints:Someone already reported the problem here, so I'll refer to those details for reproduction. Key elements are webpack v5 and WSL1 under Windows.
The directory
/mnt/c
maps to the Windows root driveC:\
, which contains these special files like the swapfile, to which the user doesn't have access. That is, the commandls /mnt/c
fails on the command line too. So it's not surprising that it fails for watchpack too.What is surprising (to me) is that watchpack attempts to list that directory to begin with. I have no config telling webpack/watchpack what to watch, only that
--watch
flag. Can someone explain this to me?